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
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
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,
On Tue, Feb 28, 2012 at 08:51, Vinay Sajip wrote:
> Lennart Regebro 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 "native" string, ie
>> one tha
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 inte
>> 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 updat
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:
http://mail
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 f
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
Lennart Regebro 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 "native" string, ie
> one that is the old 8-bit str in python 2 but a Unicode str in Py
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 "native" string, ie
one that is the old 8-bit str in python 2 but a Unicode str in Python
3.
Adding back the u'' prefix is the ea
R. David Murray bitdance.com> writes:
> The rationale claims there's no way to spell "native string" if you use
> unicode_literals, which is not true.
>
> It would be different from u('') in that I would expect that there are
> far fewer instances where 'native string' is required than there are
On Mon, 27 Feb 2012 22:11:36 +, Armin Ronacher
wrote:
> 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?
The ratio
On Tue, Feb 28, 2012 at 9:19 AM, Terry Reedy wrote:
> Since writing the above, I realized that the following is a realistic
> scenario. 2.6 or 2.7 code a) uses has/set/getattr, so unicode literals would
> require a change; b) uses non-ascii chars in unicode literals; c) uses (or
> could be convert
Brian Curtin wrote:
On Mon, Feb 27, 2012 at 17:15, Ethan Furman wrote:
This is probably a dumb question, but why can't we add u'' back to 3.2? It
seems an incredibly minor change, and we are not in security-only fix stage,
are we?
We don't add features to bug-fix releases.
Ah. Well that's
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?
Armin, I propose that you correct the *factual* deficits of the PEP
(i.e. rem
Armin Ronacher wrote:
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 Jinj
On Mon, Feb 27, 2012 at 17:15, Ethan Furman wrote:
> This is probably a dumb question, but why can't we add u'' back to 3.2? It
> seems an incredibly minor change, and we are not in security-only fix stage,
> are we?
We don't add features to bug-fix releases.
Antoine Pitrou wrote:
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman 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 pare
Armin Ronacher active-4.com> writes:
>
> 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.
Great. My part
On 2/27/2012 4:56 PM, Jim J. Jewett wrote:
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?
Since writing the above, I realized that the following i
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 Pytho
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
___
Python
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
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 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 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 m
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-De
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 pa
Well said Antoine.
--Guido van Rossum (sent from Android phone)
On Feb 27, 2012 2:03 PM, "Antoine Pitrou" wrote:
> On Mon, 27 Feb 2012 16:54:51 -0500
> Terry Reedy 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
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" wrote:
> On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
> > On 27 February 2012 20
On Mon, 27 Feb 2012 16:10:25 -0500, Chris McDonough wrote:
> On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
> > On 27 February 2012 20:39, Chris McDonough wrote:
> > > Note that u'' literals are sort of the tip of the iceberg here;
> > > supporting them will obviously not make development u
Armin Ronacher 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 just responding
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
> Chris McDonough 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, t
On Mon, 27 Feb 2012 16:16:39 -0500, Chris McDonough 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
> > different
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy 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 longe
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
Python-De
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 th
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 wa
Ethan Furman 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' for text
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.
___
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* an
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 mail
Chris McDonough 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 earlier
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman 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 parenthesis
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 test
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
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
> Chris McDonough 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. W
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
> On 27 February 2012 20:39, 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 li
On 27 February 2012 20:39, 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 th
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
> Chris McDonough 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 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 thi
Chris McDonough 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 in
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote:
> On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough 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 u
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough 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 just continue
>> 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, yo
Chris McDonough 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. Red Ha
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough 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 such a
nobrainer.
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
>>> wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
implemented in C.
>>> Even if it was quite fas
On Mon, 27 Feb 2012 10:17:57 -0800, Guido van Rossum wrote:
> On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough 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('th
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 tha
Terry Reedy 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 the Djan
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.
E
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 t
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough 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
> the
On Mon, 2012-02-27 at 12:41 -0500, 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
On Sun, 26 Feb 2012 12:42:53 +
Armin Ronacher 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 -n 1 -
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 if
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 if it was quite fast, I don't think such a function would bring
the same benefits as
Zitat von Armin Ronacher :
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
magni
1 - 100 of 124 matches
Mail list logo
