- 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
On Wed, Mar 7, 2012 at 2:36 PM, Vinay Sajip wrote:
> Armin Ronacher 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
On Thu, Mar 8, 2012 at 8:36 AM, Vinay Sajip 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 what I see as the hear
Armin Ronacher 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 get a slowdo
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 lo
On Sat, Mar 3, 2012 at 5:02 AM, Lennart Regebro 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.
>
Exactly. The r
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 exc
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 o
On Sat, Mar 3, 2012 at 11: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.
Thanks very much! It looks great to
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 impl
On Sun, Mar 4, 2012 at 11:46 PM, Armin Ronacher
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 "help", "copyright", "cre
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.
>>> u"Hello" + ' World!'
Zbigniew Jędrzejewski-Szmek 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 I'v
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.ver
Nick Coghlan 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 attempt a
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 act
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,
i
> 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).
Regar
On Sat, Mar 3, 2012 at 11:39, Vinay Sajip 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 - the text
> (Unicode
Lennart Regebro 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 clear. If
On Sat, Mar 3, 2012 at 10:26, Vinay Sajip wrote:
> Lennart Regebro 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 c
Lennart Regebro 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 con
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 3t
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 sam
On Sat, Mar 3, 2012 at 04:22, Vinay Sajip 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 consequences. For
> example,
On Sat, Mar 3, 2012 at 01:49, wrote:
>
> Zitat von 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".
>
> Ho
Guido van Rossum 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 forwa
On Fri, Mar 2, 2012 at 7:22 PM, Vinay Sajip 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)
___
Pyt
Chris McDonough 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 supp
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 n
Chris McDonough 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 that has
Zitat von 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".
How so? In the Python 3 code, the u"" prefix would not appear
On Fri, Mar 2, 2012 at 15:26, Serhiy Storchaka 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
>> binary
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 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 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
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 s
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 properl
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 so
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-awar
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?
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
Python-Dev@p
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];
* i
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
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
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 h
[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 m
On Fri, Mar 2, 2012 at 2:08 PM, Éric Araujo 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.
It's also the cas
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 bein
-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
Armin Ronacher 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 letter to literals
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 (
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
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 portin
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 list,
On Thu, 01 Mar 2012 21:12:48 +, Armin Ronacher
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 don't think tha
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 cal
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 python.org> wri
Guido van Rossum 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 a few
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
__
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
http://mail.p
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 chos
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
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
On Tue, Feb 28, 2012 at 16:39, Vinay Sajip wrote:
> Serhiy Storchaka 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.
The bytes/nativ
On Tue, Feb 28, 2012 at 16:30, Giampaolo Rodolà wrote:
> Il 28 febbraio 2012 15:20, Ezio Melotti 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
>> are big enough to make the two-bran
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 if
On Tue, Feb 28, 2012 at 13:10, Vinay Sajip 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 2.6+, 3.2 and
> 3.3+.
Le 28/02/2012 13:48, Giampaolo Rodolà a écrit :
> Il 28 febbraio 2012 13:19, Antoine Pitrou 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 mean distribut
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
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 tho
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
On 28/02/2012 18.08, Vinay Sajip wrote:
Ezio Melotti 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
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 you
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 AP
Steven D'Aprano 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 actually d
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 a
Ezio Melotti 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
> true for ano
Vinay Sajip wrote:
Serhiy Storchaka 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+
Serhiy Storchaka 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 also want to
Il 28 febbraio 2012 15:20, Ezio Melotti 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. Yes, it av
Antoine Pitrou 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* when runn
Nick Coghlan 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 unicode
On Feb 28, 2012, at 10:49 PM, Nick Coghlan wrote:
>On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou 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, but I don't. If
Armin Ronacher 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 custom wra
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 br
On Tue, 28 Feb 2012 22:21:11 +1000, Nick Coghlan wrote:
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip 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
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:
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 th
Nick Coghlan gmail.com> writes:
>
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip 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 se
On Tue, Feb 28, 2012 at 10:19 PM, 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
Il 28 febbraio 2012 13:19, Antoine Pitrou 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 uglier, but it me
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 Pyt
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip 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 which is
> integrated in
On Tue, Feb 28, 2012 at 9:52 PM, Antoine Pitrou wrote:
> On Tue, 28 Feb 2012 21:42:54 +1000
> Nick Coghlan 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
Lennart Regebro 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 Distribute hel
On Tue, 28 Feb 2012 21:42:54 +1000
Nick Coghlan 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 Python 3 yet).
Wr
On Tue, Feb 28, 2012 at 5:56 PM, Matej Cepl 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
> strings and str
On Tue, 28 Feb 2012 10:02:46 +0100
"Martin v. Löwis" 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), and the test
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,
1 - 100 of 219 matches
Mail list logo
