A couple of people have said that 'native string' is spelt 'str', but I'm not
sure that's the right answer. For example, 2.x's cString.StringIO
expects native strings, not Unicode:
Your counter-example is non-ASCII characters/bytes. I doubt that this
is a valid
use case; in a native string,
Hi,
On 2/28/12 12:16 AM, mar...@v.loewis.de wrote:
Armin, I propose that you correct the *factual* deficits of the PEP
(i.e. remove all claims that cannot be supported by facts, or are otherwise
incorrect or misleading). Many readers here would be more open to accepting
the PEP if it was
Hi,
On 2/27/12 11:54 PM, Steven D'Aprano wrote:
That would be one order of magnitude.
I am aware of that :-)
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
The PEP author is supposed to collect all arguments, even the ones he
doesn't agree with, and refute them.
I brought up all the arguments that were I knew about before I submitted
this mailinglist thread and I had since not updated it.
This is fine, of course. I still hope you will update it
Am 27.02.2012 22:35, schrieb Armin Ronacher:
Hi,
On 2/27/12 4:44 PM, mar...@v.loewis.de wrote:
Maybe I'm missing something, but there doesn't seem to be a benchmark
that measures the 2to3 performance, supporting the claim that it
runs two orders of magnitude slower (which I'd interpret as a
On Tue, Feb 28, 2012 at 08:51, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Lennart Regebro regebro at gmail.com writes:
I'm +1 on the PEP, for reasons already repeated here.
We need three types of strings when supporting both Python 2 and
Python 3. A binary string, a unicode string and a
On 28.2.2012 01:16, mar...@v.loewis.de wrote:
Armin, I propose that you correct the *factual* deficits of the PEP
He cannot, because he would have to throw away whole PEP ... it is all
based on non-sensical concept of native string. There is no such
animal (there are only strings and bytes,
On Tue, 28 Feb 2012 10:02:46 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
On the contrary, I'd expect that the build time using 2to3 is
significantly shorter than the test suite run times, *in particular*
for large projects. For example, for Django, 2to3 takes less than
3 minutes (IIRC),
On Tue, Feb 28, 2012 at 5:56 PM, Matej Cepl mc...@redhat.com wrote:
He cannot, because he would have to throw away whole PEP ... it is all based
on non-sensical concept of native string. There is no such animal (there
are only strings and bytes, although they are incorrectly named Unicode
On Tue, 28 Feb 2012 21:42:54 +1000
Nick Coghlan ncogh...@gmail.com wrote:
But the existing approaches require that, in order to be
forward compatible with Python 3, a program must be made *worse* in
Python 2 (i.e. harder to read and harder to write correctly for
someone that hasn't learned
Lennart Regebro regebro at gmail.com writes:
Distribute helps with this. I think we might have to add a support in
distribute to easily exclude the fixer that removes u''-prefixes, I
don't remember if there is an exclude feature.
We might be at cross purposes here. I don't see how
On Tue, Feb 28, 2012 at 9:52 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 28 Feb 2012 21:42:54 +1000
Nick Coghlan ncogh...@gmail.com wrote:
But the existing approaches require that, in order to be
forward compatible with Python 3, a program must be made *worse* in
Python 2 (i.e.
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
potentially involve running a fixer on all files in the project every time a
change is made, writing to a separate directory, or else a fixer
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3. Yes, it avoids making your
Python 2 code uglier, but it means maintaining two branches in
parallel until you drop Python
Il 28 febbraio 2012 13:19, Antoine Pitrou solip...@pitrou.net ha scritto:
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3. Yes, it avoids making your
Python 2 code
On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3. Yes, it avoids making your
Python 2 code
Nick Coghlan ncoghlan at gmail.com writes:
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip vinay_sajip at yahoo.co.uk
wrote:
If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
potentially involve running a fixer on all files in the project every time a
change is made,
martin at v.loewis.de writes:
A couple of people have said that 'native string' is spelt 'str', but I'm
not
sure that's the right answer. For example, 2.x's cString.StringIO
expects native strings, not Unicode:
Your counter-example is non-ASCII characters/bytes. I doubt that this
28.02.12 14:14, Nick Coghlan написав(ла):
However, that's the wrong question.
The right question is Does PEP 414 make porting substantially
*easier*, by significantly reducing the volume of code that needs to
change in order to attain Python 3 compatibility?.
Another pertinent question: What
On Tue, 28 Feb 2012 22:21:11 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
potentially involve running a fixer on all files in the project
On 28/02/2012 14.19, Antoine Pitrou wrote:
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3. Yes, it avoids making your
Python 2 code uglier, but it means maintaining two
Armin Ronacher armin.ronacher at active-4.com writes:
If by str() you mean using str('x') as replacement for 'x' in both 2.x
and 3.x with __future__ imports as a replacement for native string
literals, please mention why this is better than u(), s(), n() etc. It
would be equally slow than a
On Feb 28, 2012, at 10:49 PM, Nick Coghlan wrote:
On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
Again that's wrong. If you cleverly use 2to3 to port between branches,
patches only have to be written against the 2.x version.
Apparently *you* know how to do that,
Nick Coghlan ncoghlan at gmail.com writes:
tools. But the existing approaches require that, in order to be
forward compatible with Python 3, a program must be made *worse* in
Python 2 (i.e. harder to read and harder to write correctly for
someone that hasn't learned Python 3 yet). Restoring
Antoine Pitrou solipsis at pitrou.net writes:
Wrong. The separate branches approach allows you to have a clean
Python 3 codebase without crippling the Python 2 codebase.
There may be warts in a single codebase (you usually can't have something for
nothing), but it's not necessarily *crippled*
Il 28 febbraio 2012 15:20, Ezio Melotti ezio.melo...@gmail.com ha scritto:
On 28/02/2012 14.19, Antoine Pitrou wrote:
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3.
Serhiy Storchaka storchaka at gmail.com writes:
Another pertinent question: What are disadvantages of PEP 414 is adopted?
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x and 3.x. However, it only does this if your 3.x interest is
3.3+. If you
Vinay Sajip wrote:
Serhiy Storchaka storchaka at gmail.com writes:
Another pertinent question: What are disadvantages of PEP 414 is adopted?
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x and 3.x. However, it only does this if your 3.x
Ezio Melotti ezio.melotti at gmail.com writes:
For every CPython bug that I fix I first apply the patch on 2.7, then on
3.2 and then on 3.3.
Most of the time I don't even need to change anything while applying the
patch to 3.2, sometimes I have to do some trivial fixes. This is also
Steven D'Aprano steve at pearwood.info writes:
I don't think it's fair to say it makes it *more* painful. Fair to say it
doesn't make it less painful, but adding u'' to 3.3+ doesn't make it harder
to
port from 2.x to 3.1+. You're merely no better off with it than without it.
No, it
In the end, that's not particularly relevant, because you don't have to
run the test suite entirely; when working on small changes, you usually
re-run the impacted parts of the test suite until everything goes fine;
on the other hand, 2to3 *has* to run on the entire code base.
Not at all. If
On 28/02/2012 18.08, Vinay Sajip wrote:
Ezio Melottiezio.melottiat gmail.com writes:
For every CPython bug that I fix I first apply the patch on 2.7, then on
3.2 and then on 3.3.
Most of the time I don't even need to change anything while applying the
patch to 3.2, sometimes I have to do some
On 2/28/2012 7:10 AM, Vinay Sajip wrote:
The PEP 314 approach seems to assume that that if things work on 3.3,
they will work on 3.2/3.1/3.0 without any changes other than
replacing u'xxx' with 'xxx'.
(Delete 3.0. 3.1 is also less of a concern.) It actually assumes that if
things work on 3.3
In http://mail.python.org/pipermail/python-dev/2012-February/117070.html
Vinay Sajip wrote:
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a
single codebase across 2.x and 3.x. However, it only does this if your
3.x interest is 3.3+
For many people -- particularly those
On Feb 28, 2012, at 10:59 AM, Jim J. Jewett wrote:
For many people -- particularly those who haven't ported yet -- 3.x
will mean 3.3+. There are some who will support 3.2 because it is a
LTS release on some distribution, just as there were some who supported
Python 1.5 (but not 1.6) long into
Le 28/02/2012 13:48, Giampaolo Rodolà a écrit :
Il 28 febbraio 2012 13:19, Antoine Pitrou solip...@pitrou.net ha scritto:
IMO, maintaining two branches shouldn't be much more work than
maintaining hacks so that a single codebase works with two different
programming languages.
Would that
On Tue, Feb 28, 2012 at 13:10, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
We might be at cross purposes here. I don't see how Distribute helps, because
the use case I'm talking about is not about distributing or installing stuff,
but iteratively changing and testing code which needs to work on
All the various strategies for supporting Python 2 and Python 3 as
well as their various drawbacks and ways around this is covered in my
book, chapter 2. :-)
http://python3porting.com/strategies.html
I may be too late to point this out, but it feels like this discussion
could have been shorter
On Tue, Feb 28, 2012 at 16:30, Giampaolo Rodolà g.rod...@gmail.com wrote:
Il 28 febbraio 2012 15:20, Ezio Melotti ezio.melo...@gmail.com ha scritto:
(Note: there are also other costs -- e.g. releasing -- that I haven't
considered because they don't affect me personally, but I'm not sure they
On Tue, Feb 28, 2012 at 16:39, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Serhiy Storchaka storchaka at gmail.com writes:
Another pertinent question: What are disadvantages of PEP 414 is adopted?
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x
2012/2/27 Barry Warsaw ba...@python.org
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org wrote:
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented
in C.
Even if it was quite fast, I don't think such a function would bring
the same benefits as
There are no significant overhead to use converters.
That's because what you're benchmarking here more than anything is the
overhead of eval() :-) See the benchmark linked in the PEP for one that
measures the actual performance of the string literal / wrapper.
There are a few other unproven
Am 27.02.2012 00:07, schrieb Barry Warsaw:
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org wrote:
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python
Il 25 febbraio 2012 21:23, Armin Ronacher
armin.ronac...@active-4.com ha scritto:
Hi,
I just uploaded PEP 414 which proposes am optional 'u' prefix for string
literals for Python 3.
You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
This is a followup to the discussion
On Mon, Feb 27, 2012 at 9:34 PM, Giampaolo Rodolà g.rod...@gmail.com wrote:
If the main point of this proposal is avoiding an explicit 2to3 run on
account of 2to3 being too slow then I'm -1.
No, the main point is that adding a compile step to the Python
development process sucks. The slow speed
On Feb 27, 2012, at 12:34 PM, Giampaolo Rodolà wrote:
Il 25 febbraio 2012 21:23, Armin Ronacher
If the main point of this proposal is avoiding an explicit 2to3 run on
account of 2to3 being too slow then I'm -1.
2to3's speed isn't the only problem with the tool, although it's a big one.
It also
On Feb 27, 2012, at 11:21 AM, Martin v. Löwis wrote:
I find this rationale a bit sad: it's not that there is any (IMO) good
technical reason for the feature - only that people hate the many
available alternatives for some reason.
It makes me sad too, and as I've said, I personally have no
On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
mar...@v.loewis.de wrote:
I find this rationale a bit sad: it's not that there is any (IMO) good
technical reason for the feature - only that people hate the many
available alternatives for some reason.
But then,
Barry Warsaw barry at python.org writes:
As for the working part, I forget the details, but let's say you have a test
suite in your package. If you run `python setup.py test` in a Python 2 world,
then `python3 setup.py test` may fail to build properly. IIRC this was due to
some confusion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 AM, Giampaolo Rodolà wrote:
Il 25 febbraio 2012 21:23, Armin Ronacher
armin.ronac...@active-4.com ha scritto:
Hi,
I just uploaded PEP 414 which proposes am optional 'u' prefix for
string literals for Python 3.
You can
Hi,
On 2/27/12 10:17 AM, Martin v. Löwis wrote:
There are a few other unproven performance claims in the PEP. Can you
kindly provide the benchmarks you have been using? In particular, I'm
interested in the claim In many cases 2to3 runs one or two orders of
magnitude slower than the testsuite
Zitat von Armin Ronacher armin.ronac...@active-4.com:
Hi,
On 2/27/12 10:17 AM, Martin v. Löwis wrote:
There are a few other unproven performance claims in the PEP. Can you
kindly provide the benchmarks you have been using? In particular, I'm
interested in the claim In many cases 2to3 runs
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even if it was quite fast, I don't think such a function would bring
the
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
On Sun, 26 Feb 2012 12:42:53 +
Armin Ronacher armin.ronac...@active-4.com wrote:
Hi,
On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
Some microbenchmarks:
$ python -m timeit -n 1 -r 100 -s x = 123 'foobarbaz_%d' % x
1 loops, best of 100: 1.24 usec per loop
$ python -m timeit
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org
wrote:
A small
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough chr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
+1
Needing to change it to:
u('that')
1) Requires effort on the part of a from-Python-2-porter to service
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
The best argument is that there already exists tons and
R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even
Terry Reedy tjreedy at udel.edu writes:
This is a point, though this would be a one-time conversion by a 2to23
converter that would be part of other needed conversions, some by hand.
I presume that most 2.6 code has problems other than u'' when attempting
to run under 3.x.
Right. In doing
On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
On Mon, 27 Feb 2012 10:17:57 -0800, Guido van Rossum gu...@python.org wrote:
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough chr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
 u'that'
+1
Needing to change it
Am 27.02.2012 18:05, schrieb Ethan Furman:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org
wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
implemented in C.
Even if it was quite fast,
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonoughchr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
+1
I just don't understand the pushback here at all. This is
Chris McDonough chrism at plope.com writes:
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
But many folks aren't, and lament the slow pace of Python version adoption on
e.g.
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if you didn't, you
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough chr...@plope.com wrote:
Currently we handle 3.2 compatibility in packages that straddle via
six-like functions. We can continue doing this as necessary. If the
It seems to me that this undermines your argument in favor of u''.
Why can't you
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough chr...@plope.com wrote:
Currently we handle 3.2 compatibility in packages that straddle via
six-like functions. We can continue doing this as necessary. If the
It seems to me
Chris McDonough chrism at plope.com writes:
I really don't know how long I'll need to do future development in the
subset language of Python 2 and Python 3 because I can't predict the
future. It could be two years, it might be five. Who knows.
But I do know that I'm going to be developing
On Feb 27, 2012, at 03:39 PM, Chris McDonough wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just a tiny little bit less sucky. There
are other extremely annoying
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
But many folks aren't,
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just a tiny little bit less sucky. There
are other
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I really don't know how long I'll need to do future development in the
subset language of Python 2 and Python 3 because I can't predict the
future. It could be two years, it might be five.
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if
Hi,
On 2/27/12 4:44 PM, mar...@v.loewis.de wrote:
Maybe I'm missing something, but there doesn't seem to be a benchmark
that measures the 2to3 performance, supporting the claim that it
runs two orders of magnitude slower (which I'd interpret as a
factor of 100).
My Jinja2+Werkzeug's testsuite
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use
Chris McDonough chrism at plope.com writes:
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
Of course. And if I understand correctly, that's 2.6, 2.7, 3.2 and later
versions. I'll ignore 2.5 and
Hi,
On 2/27/12 9:36 PM, Antoine Pitrou wrote:
You don't want to be 3.2-compatible?
See the PEP. It shows how it would still be 3.2 compatible at
installation time due to an installation hook that would be provided.
Regards,
Armin
___
Python-Dev
On 2/27/2012 1:01 PM, Chris McDonough wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
Last December, Armin wrote in
http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/
And in my absolutely personal opinion Python 3.3/3.4 should be more
like Python 2*
27.02.12 22:19, Terry Reedy написав(ла):
Since u and U will go away again some year, they should only be used
for such multi-version code and not in code only intended for Python 3.
See PEP 414.
And not for code intended for both Python 2 and Python 3.0-3.2.
Ethan Furman ethan at stoneleaf.us writes:
True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
3.3.
You don't need u('') in 2.6 - why do you think you need it there?
If you don't implement this PEP, you can have, *uniformly* across 2.6, 2.7 and
all 3.x versions, 'xxx'
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
I agree. Just let's start deprecating it too, so that once Python 2.x
compatibility is no longer relevant we can eventually stop supporting
it (though that may have to
In http://mail.python.org/pipermail/python-dev/2012-February/116953.html
Terry J. Reedy wrote:
I presume that most 2.6 code has problems other than u'' when
attempting to run under 3.x.
Why?
If you're talking about generic code that has seen minimal changes
since 2.0, sure. But I think
Hi,
On 2/27/12 9:47 PM, Serhiy Storchaka wrote:
And not for code intended for both Python 2 and Python 3.0-3.2.
Even then since you can use the installation time hook to strip off the
'u' prefixes.
Regards,
Armin
___
Python-Dev mailing list
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
I agree. Just let's start deprecating it too, so that once Python 2.x
compatibility is no
On Mon, 27 Feb 2012 16:16:39 -0500, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
Yes, but making a backward step like reintroducing u'' just to make things a
tiny little bit sucky doesn't seem to me to be worth it, because then =
3.3 is
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
Of course. And if I understand correctly,
Armin Ronacher armin.ronacher at active-4.com writes:
On 2/27/12 9:36 PM, Antoine Pitrou wrote:
You don't want to be 3.2-compatible?
See the PEP. It shows how it would still be 3.2 compatible at
installation time due to an installation hook that would be provided.
I thought Antoine was
On Mon, 27 Feb 2012 16:10:25 -0500, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will
Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's
about as harmless as they come. Make it so.
--Guido van Rossum (sent from Android phone)
On Feb 27, 2012 1:12 PM, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27
Well said Antoine.
--Guido van Rossum (sent from Android phone)
On Feb 27, 2012 2:03 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback
Hi,
On 2/27/12 9:54 PM, Terry Reedy wrote:
Before we make this change, I would like to know if this is Armin's last
proposal to revert Python 3 toward Python 2 or merely the first in a
series. I question this because last December Armin wrote
You're saying as if providing a sane upgrade path
Hi,
On 2/27/12 9:58 PM, R. David Murray wrote:
But the PEP doesn't address the unicode_literals plus str() approach.
That is, the rationale currently makes a false claim.
Which would be exactly what that u() does not do?
Regards,
Armin
___
Python-Dev
On 2/27/2012 4:10 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonoughchr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the
On Feb 27, 2012, at 09:43 PM, Vinay Sajip wrote:
Well, according to the approach I described above, that one thing needs to be
the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is
native string (or whatever name you want instead of f). With the
unicode_literals import, that
On Feb 27, 2012, at 02:06 PM, Guido van Rossum wrote:
Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's
about as harmless as they come. Make it so.
I've learned that once a PEP is pronounced upon, it's usually to my personal
(if not all of our mutual :) benefit to stop
Hi,
On 2/27/12 10:29 PM, Barry Warsaw wrote:
I still urge the PEP author to clean up the PEP and specifically address the
issues brought up in this thread. That will be useful for the historical
record.
That is a given.
Regards,
Armin
___
28.02.12 00:11, Armin Ronacher написав(ла):
On 2/27/12 9:58 PM, R. David Murray wrote:
But the PEP doesn't address the unicode_literals plus str() approach.
That is, the rationale currently makes a false claim.
Which would be exactly what that u() does not do?
No.
1. u() is trivial for
1 - 100 of 124 matches
Mail list logo
