The looming Python 3(000) monster

[Michael DeHaan]

Toshio Kuratomi wrote:
> Arthur Pemberton wrote:
>   
>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>> ensure that all code is compatible with 3. And still have 3 in
>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>> to ensure everything would work with it, and for early adopters/devs
>>
>>     
> It is an oversimplification but how much is something we need experience
> in order to discover.  2.6 != 3.x even though they are close.  There
> will be a 2.7 and a 3.1 and some of those problems should be addressed
> in those two releases.  Until we actually build experience trying to do
> this, though, we don't know to what extent our work on making things
> work on 2.6 will carry over to 3.x.
>
> Note, the port we've just done to 2.6 is not all that's needed.
> python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
> deep to truly have this but it tries).  We'll have to start porting code
> to 2.6 with 3.x features turned on at some point.
>
> Also note, this is a valid plan for Fedora but it doesn't address
> mpdehaan's issue with supporting python <= 2.5 (which I don't think is
> solvable in any elegant manner.)
>
> -Toshio
>
>   
Exactly, it's not solvable in any elegant manner.

The parallel versions provides a solution for upstream, if at any point 
at which we go from 2.X to 3.0 by dropping 2.X will cause us to lose a 
lot of packages -- or lose package updates for EPEL as maintainers stop 
being able to focus on that.   Requiring an EPEL user to upgrade his 
Python to use an app isn't going to happen -- that defeats most of the 
points of stability for EL.  

Source conversation  cannot be mathematically proven and definitely 
cannot be fully automated.  It's a developers tool that results in two 
separately maintained branches.  For many applications this will be way 
too much for developers, and they will continue to maintain one or the 
other -- with differing preferences.  (Upstream's goals aren't always to 
work with a compatible Python version that we have in Fedora -- perhaps 
it's an app who's main audience is EL 5 but also wants to work in 
Fedora).   For this, we really /do/ need the split versions.

I understand why this was shot down in the past.  Then changes were 
minor, now they are intentionally larger.

These have to be treated as two different languages, even if they are 
95% similar.   (Imagine if you will, Python 2.X and 3.X being chimp and 
human, and Perl 5 and Perl 6 perhaps being archeopetryx and more 
modern-day bird) -- they still cannot interbreed.

For those who have implied I haven't know about this, yes, I've known 
about this, I've been writing Python code for at least 5-6 years.   It's 
just an excellent time to talk about it since it was just now 
"released", so that we have a solid plan for now, and if we need to 
start thinking incrementally we can.

I'm not so much trying to spell out doom, but we need to know what we 
are going to do -- and more importantly -- what the impact on our 
package list will be if we do something like drop 2.X.

--Michael