- Original Message -
But the stuff you run is not really benchmarking anything. As far as I
know django benchmarks benchmark something like mostly DB creation and
deletion, although that might differ between CPython and PyPy. How
about running *actual* django benchmarks, instead of
On Wed, Mar 7, 2012 at 2:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Armin Ronacher armin.ronacher at active-4.com writes:
What are you trying to argue? That the overall Django testsuite does
not do a lot of string processing, less processing with native strings?
I'm surprised you see
Hi,
On 3/3/12 2:28 AM, Vinay Sajip wrote:
So, looking at a large project in a relevant problem domain, unicode_literals
and native string markers would appear not to adversely impact readability or
performance.
What are you trying to argue? That the overall Django testsuite does
not do a lot
Armin Ronacher armin.ronacher at active-4.com writes:
What are you trying to argue? That the overall Django testsuite does
not do a lot of string processing, less processing with native strings?
I'm surprised you see a difference at all over the whole Django
testsuite and I wonder why you
On Thu, Mar 8, 2012 at 8:36 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Anyway, it doesn't really
matter now, since the latest version of the PEP no longer mentions those
figures.
Indeed, I deliberately removed the part about performance concerns,
since I considered it a distraction from
Nick Coghlan ncoghlan at gmail.com writes:
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Nice work - thanks!
I've implemented a first
On 03/04/2012 10:34 AM, Vinay Sajip wrote:
https://bitbucket.org/vinay.sajip/uprefix/
import uprefix; uprefix.register_hook()
import frob.subwob.subsubwob
frob.subwob.subsubwob.w
Hi,
it's pretty cool that 150 lines is enough to have this functionality.
This guard:
if sys.version_info[0]
Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl writes:
if sys.version_info[0] 3:
raise NotImplementedError('This hook is implemented for Python 3 only')
Wouldn't it be better if the hook did nothing when on python 2?
I think it'll make it necessary to use something like
Actually
Hi,
It should also be added that the Python 3.3 alpha will release with support:
Python 3.3.0a0 (default:042e7481c7b4, Mar 4 2012, 12:37:26)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
uHello + ' World!'
'Hello
On Sun, Mar 4, 2012 at 11:46 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
It should also be added that the Python 3.3 alpha will release with support:
Python 3.3.0a0 (default:042e7481c7b4, Mar 4 2012, 12:37:26)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type
Hi,
On 3/4/12 2:01 PM, Nick Coghlan wrote:
Nice :)
Do you have any more updates left to do? I saw the change, the tests,
the docs and the tokenizer updates go by on python-checkins, so if
you're done we can mark the PEP as Final (at which point the inclusion
in the first alpha is implied).
On Sat, Mar 3, 2012 at 11:34 PM, Nick Coghlan ncogh...@gmail.com wrote:
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Thanks very much! It
On Mar 04, 2012, at 05:34 PM, Nick Coghlan wrote:
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a lot more
of the historical background that was taken as read when Guido accepted the
PEP.
Nick, really great job with your rewrite of
On Sun, 2012-03-04 at 17:34 +1000, Nick Coghlan wrote:
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Just as support for string
On Sat, Mar 3, 2012 at 5:02 AM, Lennart Regebro rege...@gmail.com wrote:
I'm not sure that's true at all. In most cases where you support both
Python 2 and Python 3, most strings will be native, ie, without
prefix in either Python 2 or Python 3. The native case is the most
common case.
Lennart Regebro regebro at gmail.com writes:
So the question is if you have any proposal that is *less* confusing
while still being practical. Because we do need to distinguish between
binary, Unicode and native strings. Isn't this the least confusing
solution?
It's a matter of the degree of
On Sat, Mar 3, 2012 at 10:26, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Lennart Regebro regebro at gmail.com writes:
So the question is if you have any proposal that is *less* confusing
while still being practical. Because we do need to distinguish between
binary, Unicode and native strings.
Lennart Regebro regebro at gmail.com writes:
I'm not sure that's true at all. In most cases where you support both
Python 2 and Python 3, most strings will be native, ie, without
prefix in either Python 2 or Python 3. The native case is the most
common case.
Sorry, I didn't make myself
On Sat, Mar 3, 2012 at 11:39, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Sorry, I didn't make myself clear. If you import unicode_literals, then in
both
2.x and 3.x code, an unadorned literal string is text, and a b-adorned literal
string is bytes. My assertion was based on that assumption -
2to3 should recognize the str(string_literal) (or nstr(), or native(),
etc) as a native string and does not add prefix u to it. And you
have to explicitly specify these tips.
That is already implemented. 2to3 *never* adds a u prefix anywhere,
including not for str(string_literal).
Regards,
04.03.12 00:12, Martin v. Löwis написав(ла):
2to3 should recognize the str(string_literal) (or nstr(), or native(),
etc) as a native string and does not add prefix u to it. And you
have to explicitly specify these tips.
That is already implemented. 2to3 *never* adds a u prefix anywhere,
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Can we let the interminable discussion die now?
Please?
Regards,
Nick.
P.S. If you find an
[quoting Armin from Reddit]
Because in all honesty, because string wrappers make a codebase horrible to
work with. I will have to continue maintaining 2.x versions for at least another
four or five years. The idea if having to use string wrappers for that long
makes me puke.
Reading this led me
Yury Selivanov writes:
Otherwise, many of its points are moot, and we need to raise a
question of rejecting it somehow.
Yury, that's not going to happen. Guido made it quite clear that he
agrees with those who consider this PEP useful, obvious, and safe, and
the PEP *is* approved. There
Wiadomość napisana przez Ezio Melotti w dniu 2 mar 2012, o godz. 10:33:
Now, if the hook doesn't get in the way (AFAIU you just have to install it
and it will do its work automatically), wouldn't it be better to use it in
3.3 too (especially considering that you will probably have to use it
Hi Ezio,
Am 02.03.2012 um 10:33 schrieb Ezio Melotti:
[quoting Armin from Reddit]
Because in all honesty, because string wrappers make a codebase horrible to
work with. I will have to continue maintaining 2.x versions for at least
another
four or five years. The idea if having to use
Hi Ezio,
Am 02.03.2012 um 10:33 schrieb Ezio Melotti:
Reading this led me to think the following:
* 2.5 is now available basically everywhere, and it was released almost 5 years
ago (Sep 2006);
* if it takes the same time for 3.3, it will be widespread after 4-5 years
(i.e. 2016-2017) [0];
*
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
binary, unicode or native.
//Lennart
___
Python-Dev mailing list
02.03.12 15:49, Lennart Regebro написав(ла):
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
binary, unicode or native.
What native means in context Python 3 only?
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote:
Consider: an application that uses 8-bit strings everywhere and blows up on
non-ASCII data in Python 2 has at least a fighting chance to run unmodified
*and* handle Unicode properly on Python 3. Because unicode literals are gone,
a Unicode-aware
On Mar 02, 2012, at 12:58 PM, Hynek Schlawack wrote:
3.3 is the IMHO the first 3.x release that brings really cool stuff to the
table and might be the tipping point for people to start embracing Python 3 –
despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I
hope for some
On Fri, 2012-03-02 at 14:41 -0500, Barry Warsaw wrote:
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote:
Consider: an application that uses 8-bit strings everywhere and blows up on
non-ASCII data in Python 2 has at least a fighting chance to run unmodified
*and* handle Unicode properly on
Am 02.03.2012 um 20:44 schrieb Barry Warsaw:
3.3 is the IMHO the first 3.x release that brings really cool stuff to the
table and might be the tipping point for people to start embracing Python 3 –
despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I
hope for some
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote:
FWIW, I think this issue's webness may be overestimated. There happens to be
lots and lots of existing UI code which contains complex interactions between
unicode literals and nonliterals in web apps, but there's also likely lots of
nonweb
On Mar 02, 2012, at 09:23 PM, Hynek Schlawack wrote:
Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact
that people need more than “fine” to feel urged to switch to Python 3. I
sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we
might have a
On Fri, 2012-03-02 at 15:39 -0500, Barry Warsaw wrote:
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote:
FWIW, I think this issue's webness may be overestimated. There happens to be
lots and lots of existing UI code which contains complex interactions between
unicode literals and
On Fri, Mar 2, 2012 at 15:26, Serhiy Storchaka storch...@gmail.com wrote:
02.03.12 15:49, Lennart Regebro написав(ла):
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
Zitat von Lennart Regebro rege...@gmail.com:
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
binary, unicode or native.
How so? In the Python 3 code, the u prefix
Chris McDonough chrism at plope.com writes:
FWIW, I think this issue's webness may be overestimated. There happens
to be lots and lots of existing UI code which contains complex
interactions between unicode literals and nonliterals in web apps, but
there's also likely lots of nonweb code
PEP 414 mentions the use of function wrappers and talks about both their
obtrusiveness and performance impact on Python code. In the Django Python 3
port, I've used unicode_literals, and hence have no u prefixes in the ported
code, and use a function wrapper to adorn native strings where they are
Chris McDonough chrism at plope.com writes:
Although the change makes it possible, and it is very useful for very
low level WSGI apps, the issue this change addresses really isn't really
100% about needing to define native strings. It's also just
preservation of a resource in pretty short
On Fri, Mar 2, 2012 at 7:22 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Apparently developer energy is a limitless resource when it comes to arguing
over PEPs ;-)
Aren't *you* the one who keeps kicking this dead horse?
--
--Guido van Rossum (python.org/~guido)
Guido van Rossum guido at python.org writes:
Aren't *you* the one who keeps kicking this dead horse?
From looking at the overall thread, I'm just one of many people posting on it.
Which dead horse am I kicking? It's not as if I'm opposing anything or anyone -
just putting my point of view
On Sat, Mar 3, 2012 at 01:49, mar...@v.loewis.de wrote:
Zitat von Lennart Regebro rege...@gmail.com:
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
binary,
On Sat, Mar 3, 2012 at 04:22, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It can also have some downsides, at least according to some points of view.
For
example, I regard elevating native strings to undue prominence, and the
continued use of u'xxx' in Python 3 code, as unfortunate
Chris McDonough writes:
FWIW, I think this issue's webness may be overestimated. There happens
to be lots and lots of existing UI code which contains complex
interactions between unicode literals and nonliterals in web apps, but
there's also likely lots of nonweb code that has the same
03.03.12 08:20, Lennart Regebro написав(ла):
But you are right, it isn't necessary. I was thinking of 3to2,
actually. That was one of the objections I had to the usefulness of
3to2, there is no way to make the distinction between unicode and
native strings. (The u'' prefix hence actually makes
I noticed there were some complaints about unnecessarily offensive
language in PEP 414. Have those passages been edited to everyone's
satisfaction?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On Mar 01, 2012, at 09:42 AM, Guido van Rossum wrote:
I noticed there were some complaints about unnecessarily offensive
language in PEP 414. Have those passages been edited to everyone's
satisfaction?
Not yet, but I believe Nick volunteered to do a rewrite.
-Barry
Guido van Rossum guido at python.org writes:
I noticed there were some complaints about unnecessarily offensive
language in PEP 414. Have those passages been edited to everyone's
satisfaction?
I'm not sure if Nick has finished his updates, but I for one would like to see
some improvements in
Vinay,
Thank you for the comprehensive summary. Big +1. I really
do hope that Nick and Armin will rectify the PEP. Otherwise,
many of its points are moot, and we need to raise a question
of rejecting it somehow.
On 2012-03-01, at 2:00 PM, Vinay Sajip wrote:
Guido van Rossum guido at
Hi,
On 2/29/12 12:30 PM, Yury Selivanov wrote:
I see you've (or somebody) changed:
Yes, I reworded that.
Could you just remove the statement completely?
I will let Nick handle the PEP wording.
I don't think that PEPs are the right place to put such polemic
and biased statements.
Why call
On Thu, 01 Mar 2012 21:12:48 +, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
On 2/29/12 12:30 PM, Yury Selivanov wrote:
I see you've (or somebody) changed:
Yes, I reworded that.
Could you just remove the statement completely?
I will let Nick handle the PEP wording.
I
Hopefully, I can say the following in a constructive way. I certainly don't
mean to attack anyone personally for their closely held beliefs, though I
might disagree with them. And you have the right to those beliefs and to
express them in a respectful and constructive manner on this mailing
Hi Armin,
Sorry if I sounded like 'attacking' you. I certainly had no such
intention, as I believe nobody on this list.
But if you'd just stuck to the point, without touching very
controversial topics of what version of python is a good choice
and what is a bad, with full review of all
Hi,
On 3/1/12 10:38 PM, Yury Selivanov wrote:
Sorry if I sounded like 'attacking' you. I certainly had no such
intention, as I believe nobody on this list.
Sorry if I sound cranky but I got that impression from the responses
here (which are greatly different from the responses I got on other
On 2012-03-01, at 5:52 PM, Armin Ronacher wrote:
Hi,
On 3/1/12 10:38 PM, Yury Selivanov wrote:
Sorry if I sounded like 'attacking' you. I certainly had no such
intention, as I believe nobody on this list.
Sorry if I sound cranky but I got that impression from the responses
here (which
Armin Ronacher armin.ronacher at active-4.com writes:
I tried my best but obviously it was not good enough to please
everybody. In all honesty I did not expect that such a small change
would spawn such a great discussion. After all what we're discussing
here is the introduction of one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/01/2012 05:52 PM, Armin Ronacher wrote:
Hi,
On 3/1/12 10:38 PM, Yury Selivanov wrote:
Sorry if I sounded like 'attacking' you. I certainly had no such
intention, as I believe nobody on this list.
Sorry if I sound cranky but I got that
Hello,
Le 02/03/2012 00:15, Yury Selivanov a écrit :
And that's just the beginning of such questions. And when this PEP
was suddenly approved, many of us felt that all those questions are
not answered and were not even discussed.
Let me comment on that “suddenly”. We joke about Guido being
On Fri, Mar 2, 2012 at 2:08 PM, Éric Araujo mer...@netwok.org wrote:
I can’t read Guido’s mind, but I think that here he pronounced somewhat
quickly because he was convinced by the arguments in the PEP, while
choosing to ignore the problems therein, knowing that they could be
fixed later.
Armin,
I see you've (or somebody) changed:
As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3.
to:
As it stands, when chosing between 2.7 and
Armin,
I see you've (or somebody) changed:
As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3.
to:
As it stands, when chosing between 2.7 and
On Feb 29, 2012, at 07:30 AM, Yury Selivanov wrote:
As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3.
to:
As it stands, when chosing between 2.7
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
Hi Armin,
Could you please remove from the PEP the following statement:
As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3.
While it may be as
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
On Feb 28, 2012, at 11:29 AM, Yury Selivanov wrote:
Could you please remove from the PEP the following statement:
As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API
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
1 - 100 of 219 matches
Mail list logo
