In effect, 2to3 is a purity solution, but
six is more like a practicality solution.
This sounds like your personal interpretation. I see nothing pure in
2to3.
It's pure in being optimized for a world where you just stop using
Python 2 one day, and start using 3 the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2011 04:15 AM, Martin v. Löwis wrote:
It's pure in being optimized for a world where you just stop
using Python 2 one day, and start using 3 the next, without any
crossover support.
That's not true. 2to3 is well suited for supporting
And 2to3 is a good approach to maintaining a common code base.
Not in the experience of the folks who are actually doing that task:
Well, I personally actually *did* the task, so that experience certainly
isn't universal.
the
overhead of running 2to3 every time 'setup.py develop' etc.
Martin v. Löwis, 14.12.2011 18:23:
overhead of running 2to3 every time 'setup.py develop' etc. runs dooms
the effort.
How so? Running 2to3 after every change is very fast. I never use
setup.py develop, though.
I think the problem starts with the fact that it needs to be run in the
first
On Wed, Dec 14, 2011 at 17:33, Tres Seaver tsea...@palladion.com wrote:
Not in the experience of the folks who are actually doing that task: the
overhead of running 2to3 every time 'setup.py develop' etc. runs dooms
the effort. For instance, we have a report that the 2to3 step takes more
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough chr...@plope.com
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb and other stuff built on top of it
to Python
3 without using from __future__ import unicode_literals, I'm
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough chr...@plope.com
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb and other stuff built on top of it
to Python
3 without using from
Input = normal 2.x code; Output = code that runs on both 2.x and 3.x.
That is, tinkering with what 2to3 produces, not what it accepts.
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Dec 13, 2011 11:46 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
On
On 13/12/2011 14:24, Nick Coghlan wrote:
Input = normal 2.x code; Output = code that runs on both 2.x and 3.x.
That is, tinkering with what 2to3 produces, not what it accepts.
How is that different from what 2to3 currently does? Are you agreeing
with Laurence, suggesting an alternative, or
On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough chr...@plope.com
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb
On 13/12/2011 14:28, Laurence Rowe wrote:
On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
chr...@plope.com wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby
Laurence Rowe l at lrowe.co.uk writes:
The approach that most people seem to have settled on for porting
libraries to Python 3 is to make a single codebase that is compatible with
both Python 2 and Python 3, perhaps making use of the six library. If I
understand correctly, Chris'
On Tue, 13 Dec 2011 15:28:31 +0100
Laurence Rowe l...@lrowe.co.uk wrote:
The approach that most people seem to have settled on for porting
libraries to Python 3 is to make a single codebase that is compatible with
both Python 2 and Python 3, perhaps making use of the six library.
Do you
On Dec 13, 2011, at 05:24 PM, Antoine Pitrou wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
Laurence Rowe l...@lrowe.co.uk wrote:
The approach that most people seem to have settled on for porting
libraries to Python 3 is to make a single codebase that is compatible with
both Python 2 and
On Tue, Dec 13, 2011 at 14:33, Laurence Rowe l...@lrowe.co.uk wrote:
Could this manual work be cut down if there was a version of 2to3 that
targeted the subset of the language that is compatible with both 2 and 3?
Not really, but a 2to6, ie something that tries to keep Python 2
compatibility by
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou solip...@pitrou.netwrote:
On Tue, 13 Dec 2011 15:28:31 +0100
Laurence Rowe l...@lrowe.co.uk wrote:
The approach that most people seem to have settled on for porting
libraries to Python 3 is to make a single codebase that is compatible
with
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
Laurence Rowe l...@lrowe.co.uk mailto:l...@lrowe.co.uk wrote:
The approach that most people seem to
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which aims to do
this. It's basically 2to3, but with a package of custom fixers in a package
'lib2to23.fixers' adapted from the corresponding fixers in lib2to3.
When, some year in the
On 13/12/2011 21:10, Terry Reedy wrote:
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
Laurence Rowe l...@lrowe.co.uk mailto:l...@lrowe.co.uk wrote:
The
On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
More specifically six [1] is the name of Benjamin Peterson's support
package to help write code that works on both 2 and 3. So the idea is that
the conversion isn't just a straight syntax conversion - but that it
On Dec 14, 2011, at 08:38 AM, Nick Coghlan wrote:
String translation is also an open question. For some codebases, you
want both u and to translate to a Unicode (either in Py3k or
via the future import)
I have a fixer for this:
14.12.11 00:38, Nick Coghlan написав(ла):
String translation is also an open question. For some codebases, you
want both u and to translate to a Unicode (either in Py3k or
via the future import), but if a code base deals with WSGI-style
native strings (by means of u for text, for native, b
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which aims
to do
this. It's basically 2to3, but with a package of custom fixers in a
package
'lib2to23.fixers' adapted from the corresponding fixers in
On Tue, 13 Dec 2011 14:02:45 -0500
PJ Eby p...@telecommunity.com wrote:
Among other things, it means that:
* There's only one codebase
* If the conversion isn't perfect, you only have to fix it once
* Line numbers are the same
* There's no conversion step slowing down development
So, I
On Tue, Dec 13, 2011 at 7:30 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 13 Dec 2011 14:02:45 -0500
PJ Eby p...@telecommunity.com wrote:
Among other things, it means that:
* There's only one codebase
* If the conversion isn't perfect, you only have to fix it once
* Line
On 12/13/2011 6:36 PM, exar...@twistedmatrix.com wrote:
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which
aims to do
this. It's basically 2to3, but with a package of custom fixers in a
package
On Tue, Dec 13, 2011 at 23:38, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
More specifically six [1] is the name of Benjamin Peterson's support
package to help write code that works on both 2 and 3. So the idea is that
On Sat, 2011-12-10 at 15:55 +1000, Nick Coghlan wrote:
So I'm back to being -1 on the idea of adding back u'' literals for
3.3. Instead, people should explicitly call str() on any literals that
they want to be actual str instances both in 3.x and in 2.x when the
unicode literals future import
On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough chr...@plope.com wrote:
Truth be told, in the vast majority of WSGI apps only high-level WSGI
libraries (like WebOb and Werkzeug) and standalone middleware really
needs to work with native strings. And the middleware really should be
using the
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb and other stuff built on top of it
to Python
3 without using from __future__ import unicode_literals, I'm
kinda sad
that to be using best practice I'll have to go back and
On Tue, Dec 13, 2011 at 12:50 AM, PJ Eby p...@telecommunity.com wrote:
Unfortunately, AFAIR, nobody in the PEP discussions brought up either
the unicode_literals import OR the strategy of using a common codebase, so
2to3 on plain code and writing new Python3 code were the only porting
Am 09.12.2011 11:17, schrieb Nick Coghlan:
On Fri, Dec 9, 2011 at 8:03 PM, Terry Reedy tjre...@udel.edu wrote:
On 12/8/2011 8:39 PM, Vinay Sajip wrote:
on an
entire codebase (for example, using setup.py with flags to run 2to3
during setup).
Oh. That explains the 'slow' complaint.
As
When running 2to3 from a setup.py script, does it run on the whole
codebase or only files that are found newer by the make-like
timestamp-based dependency system?
If you run build repeatedly (e.g. in a development cycle), then
it will process only the modified files (comparing time stamps
Even in the plans that involve 2to3
though, drop everything prior to 2.6 was always supposed to be step 0,
so single codebase adds much less of a burden than I thought.
Are you talking about general porting, or about Twisted?
It is a common misconception that drop everything prior to 2.6 was
Given that WSGI 1.0.1 is defined in terms of native strings and restoring
u'' support allows that to be expressed clearly in a shared codebase, I at
least understand the point of the suggestion now. I'm not quite convinced
restoring u'' is the right answer as yet, but a solid use case is always a
Sorry, I don't understand this. What does it mean to be str in both
versions? And why would you want that?
One use case (and the only one I'm aware of) is to pass keyword
parameters. Python 2 insists that they are str (and doesn't accept
unicode), Python 3 insists that they are str (and
They fail to hear the again in that sentence. I've clearly already
thought about the distinction between bytes and text at least once:
that's *why* I'm using a u'' literal there. I shouldn't have to think
about it again to service syntax constraints. Code that is more
explicit than
Or, alternatively, you use 'six' (or a similar compatibility module)
and ensure unicode at runtime, using native or binary strings
otherwise:
--
from six import u
foo = u(this is a Unicode string in both Python 2.x and 3.x)
bar = this is an 8-bit string in Python 2.x and a Unicode
On Fri, 9 Dec 2011 15:30:36 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Or, alternatively, you use 'six' (or a similar compatibility module)
and ensure unicode at runtime, using native or binary strings
otherwise:
--
from six import u
foo = u(this is a Unicode string in both
On 12/8/2011 8:39 PM, Vinay Sajip wrote:
It's not the speed of 2to3 per se; this seems very reasonable for a
tool of its type It's the overall process, which currently involves
running 2to3
on an
entire codebase (for example, using setup.py with flags to run 2to3
during setup).
Oh. That
On Fri, Dec 9, 2011 at 8:03 PM, Terry Reedy tjre...@udel.edu wrote:
On 12/8/2011 8:39 PM, Vinay Sajip wrote:
on an
entire codebase (for example, using setup.py with flags to run 2to3
during setup).
Oh. That explains the 'slow' complaint.
As Chris pointed out though, the real problem with
On Fri, 9 Dec 2011 15:41:40 +1000
Nick Coghlan ncogh...@gmail.com wrote:
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
On Fri, Dec 9, 2011 at 03:53, Guido van Rossum gu...@python.org wrote:
Are you saying that with that future import, b... is still a Unicode
literal?
If I said that, this is not what I was trying to say. :-)
//Lennart
___
Python-Dev mailing list
Nick Coghlan writes:
So, instead of attempting to paper over the problem by reintroducing
u'', perhaps the discussion we should be having is whether or not PEP
's superficially appealing concept of defining an API in terms of
native strings is a loser in practice,
+1
to that
On Fri, Dec 9, 2011 at 04:34, Barry Warsaw ba...@python.org wrote:
Sorry, I don't understand this. What does it mean to be str in both
versions? And why would you want that?
It means that it's a str, that is a string of bytes, in Python 2, and
a str, that is a string of Unicode characters, in
Chris McDonough writes:
Given an effective choice between enabling six lines of code in Python
3.3 to support u'' and months of political wrangling and code rewriting,
I'll choose the former any day.
Sure, but the real question is whether that *is* the effective choice.
Maybe the effective
Slightly OT:
The slowness of running 2to3 during install time can be fixed by not
doing so, but instead running it when the distribution is created,
including both Python 2 and Python 3 code in the distribution.
http://python3porting.com/2to3.html#distribution-section
There are no tools that
On Dec 09, 2011, at 03:18 PM, Lennart Regebro wrote:
On Fri, Dec 9, 2011 at 04:34, Barry Warsaw ba...@python.org wrote:
Sorry, I don't understand this. What does it mean to be str in both
versions? And why would you want that?
It means that it's a str, that is a string of bytes, in Python 2,
On Dec 09, 2011, at 09:20 AM, Martin v. Löwis wrote:
One use case (and the only one I'm aware of) is to pass keyword
parameters. Python 2 insists that they are str (and doesn't accept
unicode), Python 3 insists that they are str (and doesn't accept bytes).
This is fairly uncommon as a problem,
On Dec 09, 2011, at 06:09 PM, Nick Coghlan wrote:
Given that WSGI 1.0.1 is defined in terms of native strings and restoring
u'' support allows that to be expressed clearly in a shared codebase, I at
least understand the point of the suggestion now. I'm not quite convinced
restoring u'' is the
On 9 Dec 2011, at 15:13, Barry Warsaw wrote:
On Dec 09, 2011, at 09:20 AM, Martin v. Löwis wrote:
One use case (and the only one I'm aware of) is to pass keyword
parameters. Python 2 insists that they are str (and doesn't accept
unicode), Python 3 insists that they are str (and doesn't
On 12/09/2011 08:35 AM, Michael Foord wrote:
On 9 Dec 2011, at 15:13, Barry Warsaw wrote:
Oh, I remember this one, because I think I reported and fixed it.
But I take it as a given that Python 2.6 is the minimal (sane)
version to target for one-codebase cross-Python code.
In mock (at
On Thu, 08 Dec 2011 13:27:20 +0100, Barry Warsaw ba...@python.org wrote:
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
Hi,
When running 2to3 from a setup.py script, does it run on the whole
codebase or only files that are found newer by the make-like
timestamp-based dependency system? If it’s the former, as some messages
seem to show (sorry no time to test right now), ISTM we can fix
distutils to do the latter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/09/2011 07:45 AM, Lennart Regebro wrote:
The slowness of running 2to3 during install time can be fixed by not
doing so, but instead running it when the distribution is created,
including both Python 2 and Python 3 code in the distribution.
On Dec 9, 2011, at 12:43 AM, Guido van Rossum 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 a
On Fri, Dec 9, 2011 at 10:11 AM, Barry Warsaw ba...@python.org wrote:
As Chris points out, this seems to be a use case tied to WSGI and PEP
. I
guess it's an unfortunate choice for so recent a PEP, but maybe there was
no
way to do better.
For the record, native strings are defined the
On Fri, Dec 9, 2011 at 17:38, Éric Araujo mer...@netwok.org wrote:
When running 2to3 from a setup.py script, does it run on the whole
codebase or only files that are found newer by the make-like
timestamp-based dependency system?
Only on the ones that are newer. But since at install time,
Glyph glyph at twistedmatrix.com writes:
The biggest issue for the single-codebase approach is 'except ... as ...'.
Peppering one's codebase with calls to sys.exc_info() can be a real
performance problem, especially on PyPy. Not to mention how ugly it is.
For some reason I thought that this
On Sat, Dec 10, 2011 at 5:58 AM, PJ Eby p...@telecommunity.com wrote:
In fact, I'm not sure why people are bringing it into this discussion at
all: PEP was designed to work well with 2to3, which does the right
thing for WSGI code: it converts 2.x str to 3.x str, as it should. If
you're
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
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
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 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
On the heels of Armin's blog post about the troubles of making the same
codebase run on both Python 2 and Python 3, I have a concrete
suggestion.
It would help a lot for code that straddles both Py2 and Py3 to be able
to make use of u'' literals. It would seem to be an easy thing to
reenable
1 - 100 of 106 matches
Mail list logo
