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.
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.
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.
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: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
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
Lennart Regebro regebro at gmail.com writes:
I'm +1 on the PEP, for reasons already repeated here.
We need three types of strings when supporting both Python 2 and
Python 3. A binary string, a unicode string and a native string, ie
one that is the old 8-bit str in python 2 but a Unicode str
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 -r 100 -s x = 123 str('foobarbaz_%d') % x
1 loops, best of 100: 1.59 usec per loop
$ python -m timeit -n 1 -r 100 -s x = 123
On Saturday, February 25, 2012 at 10:13 PM, 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'm all
for it.
A small quibble: I'd like to see a benchmark of a 'u' function implemented in
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 -r 100 -s x = 123 str('foobarbaz_%d') % x
1 loops, best of 100: 1.59 usec per
26.02.12 14:42, Armin Ronacher написав(ла):
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 -r 100 -s x = 123 str('foobarbaz_%d') % x
Hi,
On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher armin.ronac...@active-4.com wrote:
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/
I don't understand this sentence:
On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:
Hi,
On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher armin.ronac...@active-4.com wrote:
I just uploaded PEP 414 which proposes am optional 'u' prefix for string
literals for Python 3.
You can read the PEP online:
Hi,
On 2/26/12 5:45 PM, Antoine Pitrou wrote:
The automatic upgrading of binary strings to unicode strings that
would be enabled by this proposal would make it much easier to port
such libraries over.
What automatic upgrading is that talking about?
The word upgrade is probably something
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 3, I'm all
for it.
+1 from me for the same reasons.
If this were to go in then for Python
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 3, I'm all
for it.
+1 from me for the same
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 on the
mailinglist and on twitter/IRC over the last few weeks.
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'm all
for it.
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
--Guido
On Sat, Feb 25, 2012 at 12:23 PM, Armin Ronacher
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 restoring support for u'' literals.
Using myself
101 - 124 of 124 matches
Mail list logo
