Wiadomość napisana przez Chris McDonough w dniu 8 gru 2011, o godz. 06:08:It would make it possible to share code like this across py2 and py3: a = u'foo'As Armin himself wrote, py3k-compatible code ported from 2.x is often very ugly. This kind of change would only deepen the problem.-1Or: from
Victor Stinner victor.stin...@haypocalc.com wrote:
For localeconv(), it is the b'\xA0' byte string decoded from an encoding
looking like ISO-8859-?? (b'\xA0' is not decodable from UTF-8). It looks like
a bug in the decoder. It also looks like OpenIndiana doesn't use ISO-8859
locale anymore,
Stefan Krah ste...@bytereef.org wrote:
I'm not sure why the b'\xA0' problem only occurs in Solaris. Many systems
have this thousands separator.
Are LC_CTYPE and LC_NUMERIC set to the same value on the buildbot? Otherwise
you encounter http://bugs.python.org/issue7442 .
Stefan Krah
On 12/8/2011 1:31 AM, Chris McDonough wrote:
What's the case against?
From a 3.x perpective, an irrelevant 'u' would be pure noise and make
the language a bit harder to learn. The intent for 3.x is that one be
able to learn 3.x without knowing anything about 2.x. So bridge stuff
has been
Chris McDonough chrism at plope.com writes:
In that context, I don't see much relevance of having no support for u''
in Python 3.2.
Well, if 3.2 remains in use for a longish time, then it is relevant, in the
broader context, isn't it? We know how conservative Linux distributions can be
Nobody is using 3 yet ;)
Sure, I use it for some personal projects, and other people pretend to
support it. Not really.
The worst of the pain in porting to Python 3000 has yet to even begin!
On Thu, Dec 8, 2011 at 6:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
Such code still won't work on
On Thursday, December 08, 2011 01:18:06 AM Benjamin Peterson wrote:
Right.. the title does say readd ... support in 3.3. Are you
suggesting the ship has sailed for eternity because it can't be
supported in Python 3.3?
I'm questioning the real utility of it.
The real utility is to make
Wiadomość napisana przez Stephan Richter w dniu 8 gru 2011, o godz. 12:05:It is somewhat naive to think that you can just tell everyone to upgrade to Python 2.7 and then use the future import. Having to change all that code can also be a big bug magnet.A big bug magnet is using a Python version
On Thursday, December 08, 2011 01:08:31 PM Łukasz Langa wrote:
A big bug magnet is using a Python version that is not getting any fixes
whatsoever. When I'm backporting stuff from Python 3, I'm targeting 2.6+
because it's still somewhat supported by us. What's more important though
is that
On Dec 08, 2011, at 12:08 AM, Chris McDonough wrote:
from __future__ import unicode_literals
a = 'foo'
I agree this is an annoying thing to have to change when supporting a
dual-Python-version codebase, but it's not the most annoying. print-functions
are a little more painful to switch
On Dec 08, 2011, at 11:01 AM, Vinay Sajip wrote:
Well, if 3.2 remains in use for a longish time, then it is relevant, in the
broader context, isn't it? We know how conservative Linux distributions can
be with their Python releases - although most are still releasing 2.x as
their system Python,
If people decide to delay their Py3k migrations until they can drop 2.5
support, they're quite free to do so. The only reason for porting right now
is to support 3.2, thus making a future reintroduction of u'' useless.
Those that delay their ports can use the forward compatibility in 2.6.
Having
Le 08/12/2011 10:17, Stefan Krah a écrit :
I'm think that b'\xA0' is a valid thousands separator.
I agree, but it's not the point: the problem is that b'\xA0' is decoded
to a strange U+3020 character by mbstowcs().
Currently I have this horrible function to deal with the problem:
...
Victor Stinner victor.stin...@haypocalc.com wrote:
The problem is not directly in the C localeconv() function, but in
mbstowcs() with the hu_HU locale.
Ah, I see.
You can try my test program for this issue:
http://bugs.python.org/file23876/localeconv_wchar.c
Can't test on OpenSolaris,
Matt Joiner anacrolix at gmail.com writes:
Nobody is using 3 yet ;)
Sure, I use it for some personal projects, and other people pretend to
support it. Not really.
The worst of the pain in porting to Python 3000 has yet to even begin!
The classic chicken-and-egg problem, right?
On 08.12.2011, at 16:27, Vinay Sajip wrote:
Matt Joiner anacrolix at gmail.com writes:
Nobody is using 3 yet ;)
Sure, I use it for some personal projects, and other people pretend to
support it. Not really.
The worst of the pain in porting to Python 3000 has yet to even begin!
Jannis Leidel jannis at leidel.info writes:
I don't want to rain on your parade,
Not at all - feel free. I don't feel rained on in the least :-)
but even if your port of Django passes all tests, it's not at all near
completion. As a framework we not only have to worry about the ability to
It would make it possible to share code like this across py2 and py3:
a = u'foo'
Instead of (with e.g. six):
a = u('foo')
Or:
from __future__ import unicode_literals
a = 'foo'
I recognize that the last option is probably the way its meant to be
done, but in reality
On 12/07/2011 11:31 PM, Chris McDonough wrote:
All I can really offer is my own experience here based on writing code
that needs to straddle Python 2.5, 2.6, 2.7 and 3.2 without use of 2to3.
Having u'' work across all of these would mean porting would not require
as much eyeballing as code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/08/2011 12:26 PM, Martin v. Löwis wrote:
It would make it possible to share code like this across py2 and
py3:
a = u'foo'
Instead of (with e.g. six):
a = u('foo')
Or:
from __future__ import unicode_literals a = 'foo'
I
On Dec 8, 2011, at 7:32 AM, Nick Coghlan wrote:
Having just purged so much cruft from the language, pleas to add some back
permanently for a problem that is going to fade from significance within the
next couple of years are unlikely to get very far.
This problem is never going to go away.
This is not a comment on the success of py3, but rather the persistence
of old versions of things. Even assuming an awesomely optimistic
schedule for py3k migrations, even assuming that *everything* on PyPI
supports Py3 by the end of 2013, consider that all around the world,
every day, new
On 12/8/11 9:27 PM, Martin v. Löwis wrote:
[Glyph writes:]
Much of it is being in FORTRAN 77
Can you prove this? I trust that existing code is being maintained
in FORTRAN 77. For new code, I'm skeptical.
Personally, I've written more new code in FORTRAN 77 than in Fortran 90+. Even
with
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= mar...@v.loewis.de wrote:
While this is true for FORTRAN, it is not for Python 1.5: no new
Python 1.5 code is written around the world, at least not every day.
I don't know about that. I've seen a lot of Python 2 code which was
apparently written by
On Fri, 09 Dec 2011 00:16:02 +0100
victor.stinner python-check...@python.org wrote:
+.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode)
+
+ Get a new copy of a Unicode object.
+
+ .. versionadded:: 3.3
I'm not sure I understand. Why would you make a copy of an immutable
On 12/8/2011 10:53 AM, Jannis Leidel wrote:
possible at all). That means to reduce the number of hacks needed and
thoroughly reviewing to not suddenly lead into a maintenance dead
end. E.g. I'm still not sure the one codebase strategy is better than
the 2to3 strategy.
One codebase with
Zooming back in to the actual issue this thread is about, I think the u-vs-
issue is a bit of a red herring, because the _real_ problem here is that 2to3
is slow and buggy and so migration efforts are starting to work around it, and
therefore want to run the same code on 3.x and all the way
On Thu, 8 Dec 2011 19:52:28 -0500
Glyph gl...@twistedmatrix.com wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem here is
that 2to3 is slow and buggy and so migration efforts are starting to work
Terry Reedy tjreedy at udel.edu writes:
More that one person has said that *any* use of 2to3 is impractical for
rapid-turnaround development because 2to3 is 'too slow'. If so, have the
usual methods for speeding up a Python program been applied? Has anyone
profiled 2to3? Is most of the
On 12/8/2011 7:52 PM, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and buggy and so migration efforts are
starting to work around it, and therefore want to run the
from future import unicode_literals is my fault. I'm sorry. It's
pretty useless. It was suggested by somebody and I then supported it's
adding, instead of allowing u'' which I suggested. But it doesn't
work.
One reason is that you need to be able to say This should be str in
Python 2, and binary
Are you saying that with that future import, b... is still a Unicode
literal?
On Thu, Dec 8, 2011 at 6:50 PM, Lennart Regebro rege...@gmail.com wrote:
from future import unicode_literals is my fault. I'm sorry. It's
pretty useless. It was suggested by somebody and I then supported it's
On Fri, Dec 9, 2011 at 12:01 PM, Terry Reedy tjre...@udel.edu wrote:
On 12/8/2011 7:52 PM, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and buggy and so migration
On Dec 09, 2011, at 03:50 AM, Lennart Regebro wrote:
One reason is that you need to be able to say This should be str in
Python 2, and binary in Python 3, that should be Unicode in Python 2
and str in Python 3, and that over there should be str in both
versions, and the future import doesn't
On Dec 08, 2011, at 06:53 PM, Guido van Rossum wrote:
Are you saying that with that future import, b... is still a Unicode
literal?
No, the future import has no impact on b-strings.
-snip snip-
from __future__ import print_function
import sys
print(sys.version_info.major,
On Thu, 2011-12-08 at 22:34 -0500, Barry Warsaw wrote:
On Dec 09, 2011, at 03:50 AM, Lennart Regebro wrote:
One reason is that you need to be able to say This should be str in
Python 2, and binary in Python 3, that should be Unicode in Python 2
and str in Python 3, and that over there should
On Fri, 2011-12-09 at 03:50 +0100, Lennart Regebro wrote:
from future import unicode_literals is my fault. I'm sorry. It's
pretty useless. It was suggested by somebody and I then supported it's
adding, instead of allowing u'' which I suggested. But it doesn't
work.
One reason is that you
On Fri, Dec 9, 2011 at 2:33 PM, Chris McDonough chr...@plope.com wrote:
Continuing to not support u'' in Python 3 will be like having an
immigration station where folks who have a b'ritish' passport can get
through right away, but folks with a u'kranian' passport need to get
back on a plane
On Thu, 2011-12-08 at 19:52 -0500, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and buggy and so migration efforts are
starting to work around it, and therefore
On Fri, Dec 9, 2011 at 3:33 PM, Chris McDonough chr...@plope.com wrote:
Even if it weren't slow, I still wouldn't use it to automatically
convert code at install time; a single codebase is easier to reason
about, and easier to support. Users send me tracebacks all the time;
having them match
On Thu, Dec 8, 2011 at 9:33 PM, Chris McDonough chr...@plope.com wrote:
On Thu, 2011-12-08 at 19:52 -0500, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and
On Thu, 2011-12-08 at 21:43 -0800, Guido van Rossum wrote:
On Thu, Dec 8, 2011 at 9:33 PM, Chris McDonough chr...@plope.com
wrote:
On Thu, 2011-12-08 at 19:52 -0500, Glyph wrote:
Zooming back in to the actual issue this thread is about, I
think the
u-vs-
On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough chr...@plope.com wrote:
On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases
will have the wherewithal to compile their own Python 3 (or use a PPA or
equivalent) until the distros catch up.
So I'm not sure why 3.2 not having
On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote:
On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough chr...@plope.com wrote:
On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases
will have the wherewithal to compile their own Python 3 (or use a PPA or
equivalent) until
44 matches
Mail list logo
