[Python-Dev] Continuing 2.x
tseaver at palladion.com
Thu Oct 28 19:47:00 CEST 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 10/28/2010 12:04 PM, Barry Warsaw wrote:
> Who is the target audience for a Python 2.8? What exactly would a Python 2.8
> If Python 2.8 doesn't include new features, well, then what's the point?
> Python 2.7 will be bug fix maintained for a long time, longer in fact than
> previous Python 2 versions. So a no-feature Python 2.8 can't be about
> improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
> If Python 2.8 is about adding new features, then it has to be about
> backporting those features from Python 3.
I think that assumption may not be warranted. If the current core folks
are focused only on developing Python 3, but others are working on a
notional 2.8, there is no necessary correlation any longer between the
two. In particular, the judgement of the current core about various
tradeoffs in the Python 2 codebase won't be as relevant as it has been,
in particular because the overarching drive (add features / warnings
etc. which ease / encourage migration to Python 3) won't be in the
forefront of the new group's perspective.
> Adding new feature only to a Python 2.8 *isn't* Python, it's a fork of Python.
- From the perspective of this notional group of 2.8 developers, that
particular horse is out of the barn already: it is called "Python 3".
> Of course, it's open source and
> you're always allowed to do that, but you would need to be clear that this
> isn't "Python".
Pythonic is in the eye of the beholder.
> IOW, a distro like Ubuntu would likely never package such a
> thing as "/usr/bin/python".
For the set of folks who might care about the retro-forked 2.8, I doubt
that will matter. For instance, although I'm not (necessarily) in that
camp, I choose not to use the system python for any app I deploy: the
system packagers make tradeoffs which are inappropriate for my
applications, and I don't want to risk having a sysadmin-driven update
break them. I always build Python from source and install under '/opt'.
Distros who desire to package not-yet-or-maybe-ever-ported-to-Python-3
apps will have to make their own choices. Perhaps the retro-fork is
available via a PPA or "extras" repository, and installs explictly as
> What specific features that are showing up in say Python 3.2 are so compelling
> that they need to show up in Python 2.8, *and* would compel folks who are
> pinned to Python 2 to spend the resources to support it? Porting and
> certifying a code base against a new Python version is always work, sometimes
> a significant amount of work. What would be so compelling about a Python 2.8
> that users, package authors, and distros would be willing to undertake this
I can imagine features (and particularly library changes) which aren't
even on the radar for Python 3, which provide real value to to folks
maintaining the notional 2.8, and hence which get developed there first;
perhaps they get forward-ported later to a future Python 3 release.
> I'd *much* rather this enthusiasm be spent on making Python 3 rock, and in
> porting third party code to Python 3.
Sure you would -- you're already invested there. I would like to be
there, but can't take off the several months required to port the whole
stack under my own code.
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Python-Dev