Am 18.06.2012 17:12, schrieb Guido van Rossum:
Ok, banning ru... and ur... altogether is fine too (assuming it's
fine with the originators of the PEP).
It's gone for good. http://hg.python.org/cpython/rev/8e47e9af826e
(My first push for a very long time. Man, that feels good!)
On Wed, Jun 20, 2012 at 7:22 PM, Christian Heimes li...@cheimes.de wrote:
Am 18.06.2012 17:12, schrieb Guido van Rossum:
Ok, banning ru... and ur... altogether is fine too (assuming it's
fine with the originators of the PEP).
It's gone for good. http://hg.python.org/cpython/rev/8e47e9af826e
On 17.06.2012 22:41, Guido van Rossum wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax
is used?
Maybe we are talking about different things: The (new) proposal is that
the ur prefix in 3.3 is a syntax error (again, as it was before PEP
414). So, yes: the raw
On 6/17/2012 9:07 PM, Guido van Rossum wrote:
On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan ncogh...@gmail.com
So, perhaps the answer is to leave this as is, and try to make 2to3
smart enough to detect such escapes and replace them with their
properly encoded (according to the
But the whole point of the reintroduction of u... is to support code
that isn't run through 2to3. Frankly, I don't care how it's done, but
I'd say it's important not to silently have different behavior for the
same notation in the two versions. If that means we have to add an extra
step to
On 6/18/2012 2:06 AM, Martin v. Löwis wrote:
Hm. I still encounter enough environments that don't know how to display
such characters that I would prefer to have a rock solid \u escape
mechanism.
If you want to use them under the revised PEP 414, you will have to
avoid making them raw, and
On Mon, Jun 18, 2012 at 3:59 PM, Martin v. Löwis mar...@v.loewis.de wrote:
On 17.06.2012 22:41, Guido van Rossum wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax
is used?
Maybe we are talking about different things: The (new) proposal is that
the ur prefix in
Ok, banning ru... and ur... altogether is fine too (assuming it's fine
with the originators of the PEP).
On Sun, Jun 17, 2012 at 11:31 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jun 18, 2012 at 3:59 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
On 17.06.2012 22:41, Guido van Rossum
On Sun, Jun 17, 2012 at 10:59 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/17/2012 9:07 PM, Guido van Rossum wrote:
On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan ncogh...@gmail.com
So, perhaps the answer is to leave this as is, and try to make 2to3
smart enough to detect such
On 6/18/2012 11:12 AM, Guido van Rossum wrote:
Ok, banning ru... and ur... altogether is fine too (assuming it's
fine with the originators of the PEP).
The original PEP never proposed ur or ru , only u/U.
It turns out that ur is problematical even in 2.x, as its meaning is
changed by the
Cool.
On Mon, Jun 18, 2012 at 10:19 AM, Terry Reedy tjre...@udel.edu wrote:
On 6/18/2012 11:12 AM, Guido van Rossum wrote:
Ok, banning ru... and ur... altogether is fine too (assuming it's
fine with the originators of the PEP).
The original PEP never proposed ur or ru , only u/U.
It
Hello,
the topic came up on the python-users list today. The raw string syntax
has a minor inconsistency. The ru notation is a syntax error although
we support rb. Neither rb nor ru are supported on Python 2.7.
Python 3.3:
works: r, ur, br, rb
syntax error: ru
Python 2.7:
works: r, ur,
On Sun, Jun 17, 2012 at 9:45 PM, Christian Heimes li...@cheimes.de wrote:
Hello,
the topic came up on the python-users list today. The raw string syntax
has a minor inconsistency. The ru notation is a syntax error although
we support rb. Neither rb nor ru are supported on Python 2.7.
Python
So, while PEP 414 will allow u to run unmodified, ur will still
need to be changed to something else, because that partially escaped
behaviour isn't available in 3.x and we don't want to reintroduce it.
Given that the PEP currently explicitly supports ur, I think the
reversal of the reversal
On 6/17/2012 10:59 AM, Martin v. Löwis wrote:
So, while PEP 414 will allow u to run unmodified, ur will still
need to be changed to something else, because that partially escaped
behaviour isn't available in 3.x and we don't want to reintroduce it.
Given that the PEP currently explicitly
On Mon, Jun 18, 2012 at 3:54 AM, Terry Reedy tjre...@udel.edu wrote:
The premise of the discussion of adding 'u', and of Guido's acceptance, was
that it's about as harmless as they come. I do not remember any discussion
of 'ur' and what it really means in 2.x, and that supporting it meant
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax is
used?
--Guido van Rossum (sent from Android phone)
On Jun 17, 2012 1:13 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jun 18, 2012 at 3:54 AM, Terry Reedy tjre...@udel.edu wrote:
The premise of the discussion of
On Mon, Jun 18, 2012 at 6:41 AM, Guido van Rossum gu...@python.org wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax is
used?
Possibly - I'm trying not to actually *change* any of the internals of
the string literal processing, though. (If I recall the way we
On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jun 18, 2012 at 6:41 AM, Guido van Rossum gu...@python.org
wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax
is
used?
Possibly - I'm trying not to actually *change* any of the
On 18/06/2012 00:55, Nick Coghlan wrote:
On Mon, Jun 18, 2012 at 6:41 AM, Guido van Rossumgu...@python.org wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax is
used?
Possibly - I'm trying not to actually *change* any of the internals of
the string literal
Martin v. Löwis writes:
(this reminds me of Germany's path wrt. nuclear power
Yeah, except presumably Python won't be buying cheap raw Unicode
support from Perl. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
21 matches
Mail list logo
