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
Nick Coghlan gmail.com> writes:
> I'm pretty sure the PyPy jit can already pick up and optimise cases
> where a dict goes "read-only" (i.e. stops being modified).
No, it doesn't. We handle cases like a type's dict, or a module's dict,
by having them use a different internal implementation (while
On Tue, Feb 28, 2012 at 9:34 AM, Victor Stinner
wrote:
>>> The blacklist implementation has a major issue: it is still possible
>>> to call write methods of the dict class (e.g. dict.set(my_frozendict,
>>> key, value)).
>>
>> It is also possible to use ctypes and violate even more invariants.
>> F
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
Terry Reedy wrote:
On 2/27/2012 6:50 AM, Antoine Pitrou wrote:
'rc' makes sense to most people while 'c' is generally unheard of.
'rc' following 'a' and 'b' only makes sense to people who are used to it
and know what it means. 'c' for 'candidate' makes more sense to me both
a decade ago and
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 PM, Victor Stinner wrote:
> tuple and frozenset can only contain immutables values.
Tuples can contain mutables::
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "cred
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
>> The blacklist implementation has a major issue: it is still possible
>> to call write methods of the dict class (e.g. dict.set(my_frozendict,
>> key, value)).
>
> It is also possible to use ctypes and violate even more invariants.
> For most purposes, this falls under "consenting adults".
My pr
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:52, Barry Warsaw написав(ла):
On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote:
Indeed I have three other PEPs in the work. The reintroduction of
"except (((ExceptionType),),)", the"<>" comparision operator and the
removal of "nonlocal", the latter to make Python 2.x developers fe
On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote:
>Indeed I have three other PEPs in the work. The reintroduction of
>"except (((ExceptionType),),)", the "<>" comparision operator and the
>removal of "nonlocal", the latter to make Python 2.x developers feel
>better about themselves. :-)
One of
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html
Victor Stinner proposed:
> The blacklist implementation has a major issue: it is still possible
> to call write methods of the dict class (e.g. dict.set(my_frozendict,
> key, value)).
It is also possible to use ctypes and
Hi,
On 2/27/12 10:18 PM, Terry Reedy wrote:
> I would like to know if you think that this one change is enough to do
> agile development and testing, etc, or whether, as Chris McDonough
> hopes, this is just the first of a series of proposals you have planned.
Indeed I have three other PEPs in t
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
On 2/27/2012 10:44 AM, Armin Ronacher wrote:
On 2/27/12 1:55 AM, Terry Reedy wrote:
I presume such a hook would simply remove 'u' prefixes and would run
*much* faster than 2to3. If such a hook is satisfactory for 3.2, why
would it not be satisfactory for 3.3?
Agile development and unittests.
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
> This may be an issue at the C level (I'm not sure), but since this would
> be a Python 3-only collection, "user" code (in Python) should/would
> generally be using abstract base classes, so type-checking would not
> be an issue (as in Python code performing `isinstance(a, dict)` checks
> naturall
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 2012-02-27, at 19:53 , Victor Stinner wrote:
> Rationale
> =
>
> A frozendict type is a common request from users and there are various
> implementations. There are two main Python implementations:
>
> * "blacklist": frozendict inheriting from dict and overriding methods
> to raise a
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
Benjamin Peterson wrote:
2012/2/27 Ethan Furman :
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan :
Thanks for writing that up. I'd be amenable if the PEP was clearly
updated to say that ``raise exc from cause`` would change from being
syntactic sugar for ``_hidden = exc; _hidden.__cause__ = c
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 2/27/2012 6:50 AM, Antoine Pitrou wrote:
'rc' makes sense to most people while 'c' is generally unheard of.
'rc' following 'a' and 'b' only makes sense to people who are used to it
and know what it means. 'c' for 'candidate' makes more sense to me both
a decade ago and now. 'rc' is incons
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:
> > An installation hook means that you need to install the package
> > before running the tests. Which is fine for CI but horrible during
> > development. "python3 run-tests.py" beats "make venv; install
> > library; run testsuite" anytime in terms of development
Antoine Pitrou wrote:
On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan wrote:
+def get_output(self, code, filename=None):
+"""
+Run the specified code in Python (in a new child process)
and read the
+output from the standard error or from a file (if filename
is set).
2012/2/27 Ethan Furman :
> Benjamin Peterson wrote:
>>
>> 2012/2/26 Nick Coghlan :
>>>
>>> Thanks for writing that up. I'd be amenable if the PEP was clearly
>>> updated to say that ``raise exc from cause`` would change from being
>>> syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause;
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
On 2/27/2012 10:44 AM, Armin Ronacher wrote:
On 2/27/12 1:55 AM, Terry Reedy wrote:
I presume such a hook would simply remove 'u' prefixes and would
run *much* faster than 2to3. If such a hook is satisfactory for
3.2, why would it not be satisfactory for 3.3?
Agile development and unittests.
Rationale
=
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
* "blacklist": frozendict inheriting from dict and overriding methods
to raise an exception when trying to modify the frozendict
* "whitelist":
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
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan :
Thanks for writing that up. I'd be amenable if the PEP was clearly
updated to say that ``raise exc from cause`` would change from being
syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise
exc`` (as it is now) to ``_hidden = exc;
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
On Mon, Feb 27, 2012 at 5:44 PM, Armin Ronacher
wrote:
> Agile development and unittests. An installation hook means that you
> need to install the package before running the tests. Which is fine for
> CI but horrible during development. "python3 run-tests.py" beats "make
> venv; install librar
2012/2/26 Nick Coghlan :
> Thanks for writing that up. I'd be amenable if the PEP was clearly
> updated to say that ``raise exc from cause`` would change from being
> syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise
> exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ =
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 tes
Hi,
On 2/27/12 1:55 AM, Terry Reedy wrote:
> I presume such a hook would simply remove 'u' prefixes and would run
> *much* faster than 2to3. If such a hook is satisfactory for 3.2, why
> would it not be satisfactory for 3.3?
Agile development and unittests. An installation hook means that you
n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 AM, Giampaolo Rodolà wrote:
> Il 25 febbraio 2012 21:23, Armin Ronacher
> 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 onl
Barry Warsaw 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 that
On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
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, practicalit
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 pr
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:40 AM, Éric Araujo wrote:
> They’re all implemented in packaging/distutils2. Sadly, all of them
>have rather serious issues, so I wanted to ask what the process should
>be to solve the problems and mark the PEPs final.
From a process point of view, I'd say you should fix
On Mon, Feb 27, 2012 at 9:04 PM, vinay.sajip wrote:
> +There is, however, a way that you can use {}- and $- formatting to construct
> +your individual log messages. Recall that for a message you can use an
> +arbitrary object as a message format string, and that the logging package
> will
> +call
On Mon, Feb 27, 2012 at 9:34 PM, Giampaolo Rodolà 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 of 2to3 is one f
On Mon, 27 Feb 2012 11:40:08 +0100
Éric Araujo wrote:
>
> In PEP 386, the rule that versions using an 'rc' marker should sort
> after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 ==
> 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly
> before the PEP was acce
On Mon, Feb 27, 2012 at 12:40, Éric Araujo wrote:
> In PEP 386, the rule that versions using an 'rc' marker should sort
> after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 ==
> 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly
> before the PEP was accepted (se
Il 25 febbraio 2012 21:23, Armin Ronacher
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 about this topic here
Hello,
The three packaging-related PEPs that were written by the distutils
SIG and approved two years ago are still marked as Accepted, not Finished:
SA 345 Metadata for Python Software Packages 1.2 Jones
SA 376 Database of Installed Python Distributions Ziadé
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 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 3, I
>> 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 unpro
> Much of the software I work on is Python 3 compatible, but it's still
> used primarily on Python 2. Because most people still care primarily
> about Python 2, and most don't have a lot of Python 3 experience, it's
> extremely common to see folks submitting patches with u'' literals in
> them.
T
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 restoring s
1 - 100 of 102 matches
Mail list logo
