py3k concerns. An example
gagsl-py2 at yahoo.com.ar
Fri Apr 25 12:27:35 CEST 2008
En Thu, 24 Apr 2008 11:10:55 -0300, Paul McGuire <ptmcg at austin.rr.com>
> On Apr 21, 9:01 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
>> Perhaps you can manage to keep your code compatible with all versions,
>> AFAIK the reccomended strategy is to write code compatible with Python
>> and use the 2to3 tool to generate the 3.0 source. And *not* edit the
>> code unless one wants to maintain two branches.
> Gabriel -
> (Thanks for chiming in on this sub-thread, I really enjoy reading your
(And I enjoy using your parser! Not that I have to parse text so often,
but when it comes, the "pythonicity" of pyparsing is a great thing!)
> My point is that the recommended strategy MAY work for those who write
> end point applications (I consider maintaining 2 branches to be in the
> "not working" category), but it does NOT WORK for people who maintain
> modules for other people to use, because those people may be on a
> range of Python versions that extend beyond 2.6-3.0. So if I upgrade
> my module to 2.6, those running on earlier versions can no longer use
> it. At some point in the future, I'll probably be able to say "no
> more support for pre-2.6", but it is a bit early to start saying that
> Likewise, I don't want to say "no support for 3.0" - people DO want to
> try 3.0 out, and I WANT them to want and be able to use my module too.
> Given the recommended strategy, and ruling out dual codebase, whom do
> I tell that they can't use the next version of my module?
Ok, code that is "2.6 compatible" doesn't mean that it only runs on 2.6...
I'm *trying* to write code that is "2to3 friendly" but anyway compatible
with older Python versions, and it should not require 2.6 to run. That
means not using "with" as a variable name, for example. (And on the other
side, also refrain from using some new 2.6 features like class decorators
and binary literals)
I hope the final version of the 2to3 tool will be a little more robust -
or at least, that one will always be able to write code in a way that it
can handle (and I *dont* want to maintain a 2.x and 3.x branches of any
Based on my limited experience I'd say that this approach *could* work,
that is, write the code base for 2.x (x >= 3, in my case) and
automatically convert to 3.0. That last stage may fail, but -I hope!- not
so often in the future. As always, YMMV...
Also note that I *don't* write code for other developers (thanks God!),
just final users (with Python 2.3/4/5)
> Again, to me, this is a non-issue because I've been able to create a
> cross-version compatible single codebase for pyparsing. But it was a
> bit dicey there for a while, and I think other module developers/
> maintainers may not be so lucky.
That's a bit tricky at least. How did you manage to avoid problems with
(string/unicode) and (bytes/string) in 3.0?
> So, I feel that the recommended strategy was devised with a narrow
> group of developers in mind, and leaves module developers/maintainers,
> who wish to target as broad a set of users as possible, faced with
> choosing one of these strategies:
> - create (if possible) single cross-version compatible code
> - forego support of 3.0 users
> - discontinue pre-2.6 support for future versions of their module
> - maintain dual codebase
I hope the first alternative will be actually viable, perhaps with help
from tools like 2to3...
More information about the Python-list