py3k concerns. An example

[Gabriel Genellina]

En Thu, 24 Apr 2008 11:10:55 -0300, Paul McGuire <ptmcg at austin.rr.com>  
escribió:

> On Apr 21, 9:01 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> 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