py3k concerns. An example

[Paul McGuire]

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.)

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?

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.

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

-- Paul