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 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, only UTF-8 locales (whic
Stefan Krah 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 pu
Chris McDonough 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
with th
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 wrote:
> Such code still won't work on 3.2, hence restoring
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
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 tha
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 b
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 j
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 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, since Oracle removed the pac
Matt Joiner 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? Someone's g
On 08.12.2011, at 16:27, Vinay Sajip wrote:
> Matt Joiner 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 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 run
> on
> 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"
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 modifi
-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_lite
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 aw
> 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, n
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 a
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= 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 folks who learned
On Fri, 09 Dec 2011 00:16:02 +0100
victor.stinner 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
object?
___
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 version
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 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 the
Terry Reedy 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 time spe
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 binar
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 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 o
On Fri, Dec 9, 2011 at 12:01 PM, Terry Reedy 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 effo
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, sys.version
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 ther
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
On Fri, Dec 9, 2011 at 2:33 PM, Chris McDonough 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 that appears t
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 theref
On Fri, Dec 9, 2011 at 3:33 PM, Chris McDonough 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 the source is
On Thu, Dec 8, 2011 at 9:33 PM, Chris McDonough 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 buggy 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
> 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
On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough 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 support for u'
On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote:
> On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough 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
44 matches
Mail list logo
