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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
