«

Please consistency.

>>> sys.version
'3.3.0a4 (v3.3.0a4:7c51388a3aa7+, May 31 2012, 20:15:21) [MSC v.1600
32 bit (Intel)]'
>>> 'a'
'a'
>>> b'a'
b'a'
>>> br'a'
b'a'
>>> rb'a'
b'a'
>>> u'a'
'a'
>>> ur'a'
'a'
>>> ru'a'
SyntaxError: invalid syntax
>>>

jmf

On Sat, 16 Jun 2012 10:36:42 -0700, jmfauth wrote:

> Please consistency.

There is no point asking here. Feature requests and bug reports must go
on the tracker, or they are unlikely to be noticed or remembered by
anyone who can fix it.

http://bugs.python.org/


Given that 3.3's feature-freeze is only days away, I strongly recommend
that you also raise it here:

http://mail.python.org/mailman/listinfo/python-dev




--
Steven

On 16.06.12 20:36, jmfauth wrote:
>>>> u'a'
> 'a'
>>>> ur'a'
> 'a'

Please, never use u'' in new Python 3 code. This is only for
compatibility with Python 2. And Python 2 does not support ru''.

On 17 juin, 13:30, Christian Heimes <li...@cheimes.de> wrote:
> Am 16.06.2012 19:36, schrieb jmfauth:
>
> > Please consistency.
>
> Python 3.3 supports the ur"" syntax just as Python 2.x:
>
> $ ./python
> Python 3.3.0a4+ (default:4c704dc97496, Jun 16 2012, 00:06:09)
> [GCC 4.6.3] on linux
> Type "help", "copyright", "credits" or "license" for more information.>>> ur""
>
> ''
> [73917 refs]
>
> Neither Python 2 nor Python 3 supports ru"". I'm a bit astonished that
> rb"" works in Python 3 as it doesn't work in Python 2.7. But br"" works
> everywhere.
>
> Christian

I noticed this at the 3.3.0a0 realease.

The main motivation for this came from this:
http://bugs.python.org/issue13748

PS I saw the dev-list message.

PS2 Opinion, if not really useful, consistency nver hurts.

jmf

On Sun, 17 Jun 2012 05:11:25 -0700, jmfauth wrote:

> PS2 Opinion, if not really useful, consistency nver hurts.

If you're doing something useless or harmful, why would you want to do
more of it for the sake of consistency?

"Consistency" requires somebody to write the code in the first place,
which isn't free. If you don't have to pay for it, *somebody* pays for
it, even if it is only in their own time and effort. That's a real cost.

Somebody has to write the code, update the documentation and create tests
for it. Somebody else has to review the code. Every single time Python's
test suite is run, extra tests are run. More code means greater chance of
bugs or regressions. These are real costs.

Python programmers have to learn the new functionality, which may or may
not be simple. Every time they write a string, they have to decide which
delimiter to use: currently, there are 16 in Python 2, and a similar
number in Python 3 (more? fewer? I'm honestly not sure). That decision
isn't free. Your proposal would add four more string delimiters.

Now these may all be *small* costs, perhaps. They might be small enough
that consistency for its own sake outweighs those costs. Maybe. But
consistency doesn't happen for free. So it is not true that consistency
*never* hurts. Consistency ALWAYS hurts, at least a bit, because it adds
complexity. The only question is whether or not the benefit outweighs the
harm. Often it will, but that can't be taken for granted.

"A foolish consistency is the hobgoblin of little minds"
- Ralph Waldo Emerson



--
Steven

On 17 juin, 15:48, Christian Heimes <li...@cheimes.de> wrote:
> Am 17.06.2012 14:11, schrieb jmfauth:
>
> > I noticed this at the 3.3.0a0 realease.
>
> > The main motivation for this came from this:
> >http://bugs.python.org/issue13748
>
> > PS I saw the dev-list message.
>
> > PS2 Opinion, if not really useful, consistency nver hurts.
>
> We are must likely drop the ur"" syntax as it's not compatible with
> Python 2.x's raw unicode notation.http://bugs.python.org/issue15096
>
> Christian


Yes, but on the other side, "you" (core developers) have reintroduced
the
messs of the unicode literal, now *assume* it (logiccally).

If the core developers have introduced rb'' or br' (Py2)' because they
never
know if the have to type "rb" or "br" (me too), what a beginner should
thing about "ur" and "ru"?

Finally, the ultimate argument: what it is Python 3 supposed to be?
A Python 2 derivative for lazy (ascii) programmers or an appealing
clean and coherent language?

jmf