[Python-3000] Code working in both 2.x and 3.X

[Ron Adam]

Jim Jewett wrote:
> Raymond Hettinger wrote:
> 
>> Also, I'm wondering if the desire for 2.6 warnings is based on the notion that
>> it will be possible to get large tools to work under both Py2.x and Py3.x.
> 
> I had certainly assumed it would be possible.
> 
> In fact, I had assumed that the 2->3 translator would have a mode
> which left the code running in both.
> 
> This might not be the cleanest possible code for either line (parens
> in 2.x, some extra iter calls or missed shortcuts, etc), but it should
> certainly exist.  If it doesn't, then people who do want to support
> both lines will themselves have to work exclusively in 2.x and
> "compile" to 3.x.
> 
>> With all the module renaming/packaging,
[etc... clipped to shorten]

There seems to be a fair amount of anxiety starting to appear about the 
difficulty of trying to support both 2.x and 3.x at the same time.  It's 
understandable, but I think it may be the earlier than expected 3.0 release date 
that is adding to that.

Would it be reasonable to define X.0.X versions as official transition versions 
which need not have both back word compatibility, or overly strict future 
compatibility?

I thinking that the 3.0.X version be considered a try it out (alpha) release to 
generate plenty of feed back, and the 3.1.X version be the first version meant 
for actual development use.

    3.0.X <=> 3.alpha.X
    3.1.X <=> 3.first.X

So the release order may be 3.0.0, 2.6.0, 3.1.0. ...

(With minor bug fix releases in between, of course.)

My thinking is developers won't need to support the 3.0.X version *ever*.  And 
even 3.1.X need not be "too strongly" constrained to be back word compatible 
with version 3.0.X, as it may still have quite a few changes.  Version 3.1.0 
would then be the first version that future, 3.(1+n), versions will need to 
maintain back words compatibility with.

This gives a lot more time for developers to try it, give feed back, and work 
out how to do things like move stuff from 2.X to 3.X, etc...  It also may give 
more freedom to make changes in version 3.0 with less anxiety to third party 
developers.

Version 3.0  ->  a (relatively) clean start with big changes.

Version 2.6  ->  may take into account things in version 3.0.

Version 3.1  ->  builds on 3.0 and may take into account version 2.6


Isn't this the general (informal) context already being considered?


Just a few thoughts,
   Ron