[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The looming Python 3(000) monster



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]