En Thu, 24 Apr 2008 11:10:55 -0300, Paul McGuire <[EMAIL PROTECTED]>
escribió:
On Apr 21, 9:01 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
Perhaps you can manage to keep your code compatible with all versions,
but
AFAIK the reccomended strategy is to write code compatible with Python
2.6
and use the 2to3 tool to generate the 3.0 source. And *not* edit the
3.0
code unless one wants to maintain two branches.
Gabriel -
(Thanks for chiming in on this sub-thread, I really enjoy reading your
posts.)
(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
now.
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
code either)
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...
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
