2012/2/27 Barry Warsaw ba...@python.org
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org wrote:
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python
Nick Coghlan ncoghlan at gmail.com writes:
It's half the puzzle (since composing the event fields into the actual
log output is a logger action, you know the style when you supply the
format string). The other half is that logging's lazy formatting
currently only supporting printf-style
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented
in C.
Even if it was quite fast, I don't think such a function would bring
the same benefits as
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.
These
There are no significant overhead to use converters.
That's because what you're benchmarking here more than anything is the
overhead of eval() :-) See the benchmark linked in the PEP for one that
measures the actual performance of the string literal / wrapper.
There are a few other unproven
Am 27.02.2012 00:07, schrieb Barry Warsaw:
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org wrote:
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python
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
Il 25 febbraio 2012 21:23, Armin Ronacher
armin.ronac...@active-4.com ha scritto:
Hi,
I just uploaded PEP 414 which proposes am optional 'u' prefix for string
literals for Python 3.
You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
This is a followup to the discussion
On Mon, Feb 27, 2012 at 12:40, Éric Araujo mer...@netwok.org 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
On Mon, 27 Feb 2012 11:40:08 +0100
Éric Araujo mer...@netwok.org 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
On Mon, Feb 27, 2012 at 9:34 PM, Giampaolo Rodolà g.rod...@gmail.com wrote:
If the main point of this proposal is avoiding an explicit 2to3 run on
account of 2to3 being too slow then I'm -1.
No, the main point is that adding a compile step to the Python
development process sucks. The slow speed
On Mon, Feb 27, 2012 at 9:04 PM, vinay.sajip python-check...@python.org 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
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 Feb 27, 2012, at 12:34 PM, Giampaolo Rodolà wrote:
Il 25 febbraio 2012 21:23, Armin Ronacher
If the main point of this proposal is avoiding an explicit 2to3 run on
account of 2to3 being too slow then I'm -1.
2to3's speed isn't the only problem with the tool, although it's a big one.
It also
On Feb 27, 2012, at 11:21 AM, Martin v. Löwis wrote:
I find this rationale a bit sad: it's not that there is any (IMO) good
technical reason for the feature - only that people hate the many
available alternatives for some reason.
It makes me sad too, and as I've said, I personally have no
On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
mar...@v.loewis.de wrote:
I find this rationale a bit sad: it's not that there is any (IMO) good
technical reason for the feature - only that people hate the many
available alternatives for some reason.
But then,
Barry Warsaw barry at python.org writes:
As for the working part, I forget the details, but let's say you have a test
suite in your package. If you run `python setup.py test` in a Python 2 world,
then `python3 setup.py test` may fail to build properly. IIRC this was due to
some confusion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 AM, Giampaolo Rodolà wrote:
Il 25 febbraio 2012 21:23, Armin Ronacher
armin.ronac...@active-4.com ha scritto:
Hi,
I just uploaded PEP 414 which proposes am optional 'u' prefix for
string literals for Python 3.
You can
Hi,
On 2/27/12 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
Hi,
On 2/27/12 10:17 AM, Martin v. Löwis wrote:
There are a few other unproven performance claims in the PEP. Can you
kindly provide the benchmarks you have been using? In particular, I'm
interested in the claim In many cases 2to3 runs one or two orders of
magnitude slower than the testsuite
2012/2/26 Nick Coghlan ncogh...@gmail.com:
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 5:44 PM, Armin Ronacher
armin.ronac...@active-4.com 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
Zitat von Armin Ronacher armin.ronac...@active-4.com:
Hi,
On 2/27/12 10:17 AM, Martin v. Löwis wrote:
There are a few other unproven performance claims in the PEP. Can you
kindly provide the benchmarks you have been using? In particular, I'm
interested in the claim In many cases 2to3 runs
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even if it was quite fast, I don't think such a function would bring
the
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
On Sun, 26 Feb 2012 12:42:53 +
Armin Ronacher armin.ronac...@active-4.com wrote:
Hi,
On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
Some microbenchmarks:
$ python -m timeit -n 1 -r 100 -s x = 123 'foobarbaz_%d' % x
1 loops, best of 100: 1.24 usec per loop
$ python -m timeit
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org
wrote:
A small
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough chr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
+1
Needing to change it to:
u('that')
1) Requires effort on the part of a from-Python-2-porter to service
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan ncogh...@gmail.com:
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)
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
The best argument is that there already exists tons and
R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even
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:
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
Terry Reedy tjreedy at udel.edu writes:
This is a point, though this would be a one-time conversion by a 2to23
converter that would be part of other needed conversions, some by hand.
I presume that most 2.6 code has problems other than u'' when attempting
to run under 3.x.
Right. In doing
2012/2/27 Ethan Furman et...@stoneleaf.us:
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan ncogh...@gmail.com:
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;
Antoine Pitrou wrote:
On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan python-check...@python.org 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
Terry Reedy tjreedy at 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
On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
On Mon, 27 Feb 2012 10:17:57 -0800, Guido van Rossum gu...@python.org wrote:
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough chr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
 u'that'
+1
Needing to change it
Am 27.02.2012 18:05, schrieb Ethan Furman:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org
wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
implemented in C.
Even if it was quite fast,
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonoughchr...@plope.com wrote:
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
+1
I just don't understand the pushback here at all. This is
Chris McDonough chrism at plope.com writes:
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
But many folks aren't, and lament the slow pace of Python version adoption on
e.g.
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if you didn't, you
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough chr...@plope.com wrote:
Currently we handle 3.2 compatibility in packages that straddle via
six-like functions. We can continue doing this as necessary. If the
It seems to me that this undermines your argument in favor of u''.
Why can't you
On 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
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough chr...@plope.com wrote:
Currently we handle 3.2 compatibility in packages that straddle via
six-like functions. We can continue doing this as necessary. If the
It seems to me
Benjamin Peterson wrote:
2012/2/27 Ethan Furman et...@stoneleaf.us:
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan ncogh...@gmail.com:
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
Chris McDonough chrism at plope.com writes:
I really don't know how long I'll need to do future development in the
subset language of Python 2 and Python 3 because I can't predict the
future. It could be two years, it might be five. Who knows.
But I do know that I'm going to be developing
On Feb 27, 2012, at 03:39 PM, Chris McDonough wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just a tiny little bit less sucky. There
are other extremely annoying
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
But many folks aren't,
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just a tiny little bit less sucky. There
are other
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just
On 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 an
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I really don't know how long I'll need to do future development in the
subset language of Python 2 and Python 3 because I can't predict the
future. It could be two years, it might be five.
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
naturally
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if
Hi,
On 2/27/12 4:44 PM, mar...@v.loewis.de wrote:
Maybe I'm missing something, but there doesn't seem to be a benchmark
that measures the 2to3 performance, supporting the claim that it
runs two orders of magnitude slower (which I'd interpret as a
factor of 100).
My Jinja2+Werkzeug's testsuite
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use
Chris McDonough chrism at plope.com writes:
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
Of course. And if I understand correctly, that's 2.6, 2.7, 3.2 and later
versions. I'll ignore 2.5 and
Hi,
On 2/27/12 9:36 PM, Antoine Pitrou wrote:
You don't want to be 3.2-compatible?
See the PEP. It shows how it would still be 3.2 compatible at
installation time due to an installation hook that would be provided.
Regards,
Armin
___
Python-Dev
On 2/27/2012 1:01 PM, Chris McDonough wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
Last December, Armin wrote in
http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/
And in my absolutely personal opinion Python 3.3/3.4 should be more
like Python 2*
27.02.12 22:19, Terry Reedy написав(ла):
Since u and U will go away again some year, they should only be used
for such multi-version code and not in code only intended for Python 3.
See PEP 414.
And not for code intended for both Python 2 and Python 3.0-3.2.
Ethan Furman ethan at stoneleaf.us writes:
True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
3.3.
You don't need u('') in 2.6 - why do you think you need it there?
If you don't implement this PEP, you can have, *uniformly* across 2.6, 2.7 and
all 3.x versions, 'xxx'
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
I agree. Just let's start deprecating it too, so that once Python 2.x
compatibility is no longer relevant we can eventually stop supporting
it (though that may have to
In http://mail.python.org/pipermail/python-dev/2012-February/116953.html
Terry J. Reedy wrote:
I presume that most 2.6 code has problems other than u'' when
attempting to run under 3.x.
Why?
If you're talking about generic code that has seen minimal changes
since 2.0, sure. But I think
Hi,
On 2/27/12 9:47 PM, Serhiy Storchaka wrote:
And not for code intended for both Python 2 and Python 3.0-3.2.
Even then since you can use the installation time hook to strip off the
'u' prefixes.
Regards,
Armin
___
Python-Dev mailing list
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback here at all. This is such a
nobrainer.
I agree. Just let's start deprecating it too, so that once Python 2.x
compatibility is no
On Mon, 27 Feb 2012 16:16:39 -0500, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
Yes, but making a backward step like reintroducing u'' just to make things a
tiny little bit sucky doesn't seem to me to be worth it, because then =
3.3 is
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
Of course. And if I understand correctly,
Armin Ronacher armin.ronacher at active-4.com writes:
On 2/27/12 9:36 PM, Antoine Pitrou wrote:
You don't want to be 3.2-compatible?
See the PEP. It shows how it would still be 3.2 compatible at
installation time due to an installation hook that would be provided.
I thought Antoine was
On Mon, 27 Feb 2012 16:10:25 -0500, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will
Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's
about as harmless as they come. Make it so.
--Guido van Rossum (sent from Android phone)
On Feb 27, 2012 1:12 PM, Chris McDonough chr...@plope.com wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27
Well said Antoine.
--Guido van Rossum (sent from Android phone)
On Feb 27, 2012 2:03 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/27/2012 1:17 PM, Guido van Rossum wrote:
I just don't understand the pushback
Hi,
On 2/27/12 9:54 PM, Terry Reedy wrote:
Before we make this change, I would like to know if this is Armin's last
proposal to revert Python 3 toward Python 2 or merely the first in a
series. I question this because last December Armin wrote
You're saying as if providing a sane upgrade path
Hi,
On 2/27/12 9:58 PM, R. David Murray wrote:
But the PEP doesn't address the unicode_literals plus str() approach.
That is, the rationale currently makes a false claim.
Which would be exactly what that u() does not do?
Regards,
Armin
___
Python-Dev
On 2/27/2012 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
On 2/27/2012 4:10 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonoughchr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the
On Feb 27, 2012, at 09:43 PM, Vinay Sajip wrote:
Well, according to the approach I described above, that one thing needs to be
the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is
native string (or whatever name you want instead of f). With the
unicode_literals import, that
On Feb 27, 2012, at 02:06 PM, Guido van Rossum wrote:
Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's
about as harmless as they come. Make it so.
I've learned that once a PEP is pronounced upon, it's usually to my personal
(if not all of our mutual :) benefit to stop
Hi,
On 2/27/12 10:29 PM, Barry Warsaw wrote:
I still urge the PEP author to clean up the PEP and specifically address the
issues brought up in this thread. That will be useful for the historical
record.
That is a given.
Regards,
Armin
___
28.02.12 00:11, Armin Ronacher написав(ла):
On 2/27/12 9:58 PM, R. David Murray wrote:
But the PEP doesn't address the unicode_literals plus str() approach.
That is, the rationale currently makes a false claim.
Which would be exactly what that u() does not do?
No.
1. u() is trivial for
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 the
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
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 them's a
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 feel
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
Armin Ronacher armin.ronacher at 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.
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 primary
Antoine Pitrou wrote:
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing
On Mon, Feb 27, 2012 at 17:15, Ethan Furman et...@stoneleaf.us 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.
-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, credits
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
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.
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
Brian Curtin wrote:
On Mon, Feb 27, 2012 at 17:15, Ethan Furman et...@stoneleaf.us 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.
On Tue, Feb 28, 2012 at 9:34 AM, Victor Stinner
victor.stin...@gmail.com 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
Nick Coghlan ncoghlan at 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
On Tue, Feb 28, 2012 at 9:19 AM, Terry Reedy tjre...@udel.edu 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
On Mon, 27 Feb 2012 22:11:36 +, Armin Ronacher
armin.ronac...@active-4.com 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()
R. David Murray rdmurray at 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
1 - 100 of 102 matches
Mail list logo
