2.2.x backports of 2.3.x new features?

[Laura Creighton]

Python in a Tie is interested in finding out what, if any features
from 2.3 should be ported back to 2.2. Can you please cc me on
any discussion, or better yet cross post to snake-***@lists.lysator.liu.se?
My life is hellishly busy and I don't want to miss any of this.

Apologies for being a pain,

Thank you,
Laura Creighton

Looking through the What's New in 2.3 document, there's a number of
modules which seem like they could be readily back-ported to 2.2.x (the
"stable target" for Python). Possibly a 2.3 backports package (with the
idea that there could be a 2.4, and possibly even a 3.0 backports
package when those versions come out). The modules could break code
that does imports of the same name, but if you're installing a feature
backports package you can expect new features to have names ;) .
* sets module -- sounds as though it's a simple Python-language
module that should be compatible with 2.2
* textwrap -- sounds like a stand-alone Python module
* logging -- stand-alone Python package
* optparse -- stand-alone Python module
* heapq -- sounds like a stand-alone C module
Then there are module enhancements which seem like they could be
back-ported fairly readily, though they would have potential
namespace-clashes in certain cases. Somewhat more dangerous because
* math.degrees( rads ) and math.radians( degrees )
* random.sample
* getopt.gnu_getopt
* time.strptime -- (reliability/bug-fix), people likely willing to
eat cost on changing code which uses the current bugginess
And then there are a few built-ins that sound like they'd be useful if
you've got a 2.3 module that happens to use the features and want to
back-port it to 2.2.x. You could either install them into builtins or
* enumerate built-in function -- just a generator/function
* bool type -- basically just a minor sub-class of int
The first three modules (sets, textwrap and logging) are, to me, the
bulk of the interesting features in 2.3 (I like extended slicing
notation, but I really only find myself needing to use it with Numeric
arrays).
Is there already a 2.2.3 release Czar? Can they comment on what's on
the back-port table already (probably just the bug-fix patches), and
what would need to be in an add-on back-porting package (probably
everything above)?
Mike
...

Andrew Kuchling describes "What's new in 2.3".
http://www.python.org/dev/doc/devel/whatsnew/whatsnew23.html

...
--
http://mail.python.org/mailman/listinfo/python-list

[Mike C. Fletcher]

(comments below)

Looking through the What's New in 2.3 document, there's a number of
modules which seem like they could be readily back-ported to 2.2.x (the
"stable target" for Python).

It's not entirely clear from your post, but I get the impression you're
advocating that the modules be included in the 2.2.3+ distributions of
python. As I understand the maintenance release rules, that's never going to
happen. The maintenance releases don't include new features, ever(*).
Richard
*: unless they do <wink> (2.2.2 included a "feature update" version of the
email package, 'with special dispensation from the "bugfixes only" rule')

In fact, I am not necessarily interested in these features becoming part
of the official 2.2.x releases (that would be fine, as long as there is
a way to disable the inclusion, but it's not my particular focus).
Instead, I'm considering this more as a target for the Python in a Tie
group, which is intending to create a stable business-focused
distribution of Python.

The only reason I mentioned the 2.3.x release Czar was to ask which if
any of these features are going into the 2.2.3 release, so that the rest
of the set could be considered candidates for inclusion in a Python in a
Tie back-ports package.

The rationale for creating a back-ports package for standard-library
enhancements is fairly simple:

* the features are likely without dependency on particular 2.3.x
core functionality (there isn't much new core functionality which
is likely to have been exploited in these particular modules),
which should make the features easy to back-port
* each of these modules is considered important enough to have been
included in the standard library for 2.3.x
o this argues that the modules are likely to be useful under
2.2.x as well
* none of the particular features I've outlined have any particular
connection with functionality around them (i.e. encapsulation
makes these modules, packages and functions largely side-effect free).
o In a sense, the default distribution of Python is actually
two (or dozens, depending on how you look at it)
distributions, one being the core interpreter, the second
being the standard library (or, alternatively, the other
dozens being the individual modules and packages in the
standard library). The features provided by
standard-library 2.3.x are likely to be quite useful in
Python 2.2.x.
* although logging and Optik are likely still available separately,
the other pieces of code are not likely available as separate
packages at the moment, and the 2.3.x versions of all of the
packages are probably diverging somewhat from the original code
* even if individual modules/packages are available separately, it
would be convenient to be able to install the entire
standard-library 2.3 upgrade without needing to track down the
individual packages
* as the 2.3.x wagon rolls along, there will be 2.3.x-targeted
modules which rely on standard-library 2.3, being able to specify
a single dependency (i.e. standard library 2.3) would be convenient

Though I am not particularly interested in including the 2.3 standard
library update in maintenance releases, it might be useful for many
users to include the 2.3 standard library update as an optional
installation package in the 2.2.x maintenance release installers (I'm
thinking of the Windows installer in particular, where including a
particular package as optional allows the user to simply check or
un-check the package for installation, which would allow the user to
specify whether they want to use standard library 2.2 or standard
library 2.3).

Of course, when we finally get the Comprehensive Python Archive Network
built, these kind of packaging issues should become largely an
unpleasant memory :) , then we will simply do an update for
standard-library-2.3, which will depend on (and thereby force the
installation of) the updated versions of each of the updated
packages/modules. Until then, Python in a Tie's collection is probably
the closest thing we will have.

Enjoy yourselves,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Jeremy Hylton]

MCF> In fact, I am not necessarily interested in these features
MCF> becoming part of the official 2.2.x releases (that would be
MCF> fine, as long as there is a way to disable the inclusion, but
MCF> it's not my particular focus). Instead, I'm considering this
MCF> more as a target for the Python in a Tie group, which is
MCF> intending to create a stable business-focused distribution of
MCF> Python.

So what's the word on Python in a Tie?

I thought I understood the original motivation to be that Python
development was moving too quickly, and business people needed a more
stable release without all the new features. But maybe I
misunderstood.

It sounds like PIAT users are just like all other Python users: "We
think the developers are adding too many new features and they should
stop -- except for these features, which we really need." <0.2 wink>

What would the difference, then, be between PIAT and Python 2.3?

Jeremy

[holger krekel]

Post by Jeremy Hylton
MCF> In fact, I am not necessarily interested in these features
MCF> becoming part of the official 2.2.x releases (that would be
MCF> fine, as long as there is a way to disable the inclusion, but
MCF> it's not my particular focus). Instead, I'm considering this
MCF> more as a target for the Python in a Tie group, which is
MCF> intending to create a stable business-focused distribution of
MCF> Python.
So what's the word on Python in a Tie?
I thought I understood the original motivation to be that Python
development was moving too quickly, and business people needed a more
stable release without all the new features. But maybe I
misunderstood.
It sounds like PIAT users are just like all other Python users: "We
think the developers are adding too many new features and they should
stop -- except for these features, which we really need." <0.2 wink>
What would the difference, then, be between PIAT and Python 2.3?

Maybe that the PIAT releases would only contain updated module code
whereas Python 2.3 might also have core changes (e.g. Michael Hudson's
assignment to __bases__)?

holger

[Mike C. Fletcher]

Basically, in my understanding, PIAT will give the business developer
these features:

1. same core-language version for an extended period of time (e.g. 18
months)
1. extension modules (particularly in-house and/or proprietary
third-party ones) don't need to be recompiled (often not an
option for proprietary third-party modules)
2. no change to semantics of valid code
3. no new syntax/keywords
4. within reason, what works with the core should keep working
with it as long as the PIAT version is the same (18
months+), with the exception of dependencies of bugs
2. library of tested modules/packages which are known to work with
the core-language version
1. precompiled binaries for the various (common) open-source
extension modules
1. compiled against the stable core-language version of
Python
2. tested agains the stable core-language version of Python
2. the standard library of the core version (e.g.
standard-library 2.2)
3. (in this case) modules back-ported from later versions (e.g.
standard-library 2.3)
4. third-party modules not part of the standard library
(standard-library 2.3 could be considered a member of this set)
5. whereever possible, modules in the library should work with
all PIAT versions of the same release (that is, if there's a
module made available, it should work with 2.2.n, 2.2.n+1,
2.2.n+2, ... 2.2.m where n is the first PIAT version of 2.2
and m is the last), in other words, users aren't forced to
upgrade the core just to get a library updated _unless_ the
update to the library actually relies on a _bug fix_ in the
core.

But as I'm not a Python-in-a-Tie member, I'll let them respond
authoritatively,
Mike

Post by holger krekel

Post by Jeremy Hylton
What would the difference, then, be between PIAT and Python 2.3?

Maybe that the PIAT releases would only contain updated module code
whereas Python 2.3 might also have core changes (e.g. Michael Hudson's
assignment to __bases__)?
holger

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Laura Creighton]

Post by Mike C. Fletcher
Basically, in my understanding, PIAT will give the business developer
1. same core-language version for an extended period of time (e.g. 18
months)
1. extension modules (particularly in-house and/or proprietary
third-party ones) don't need to be recompiled (often not an
option for proprietary third-party modules)
2. no change to semantics of valid code
3. no new syntax/keywords
4. within reason, what works with the core should keep working
with it as long as the PIAT version is the same (18
months+), with the exception of dependencies of bugs
2. library of tested modules/packages which are known to work with
the core-language version
1. precompiled binaries for the various (common) open-source
extension modules
1. compiled against the stable core-language version of
Python
2. tested agains the stable core-language version of Python
2. the standard library of the core version (e.g.
standard-library 2.2)
3. (in this case) modules back-ported from later versions (e.g.
standard-library 2.3)
4. third-party modules not part of the standard library
(standard-library 2.3 could be considered a member of this set)
5. whereever possible, modules in the library should work with
all PIAT versions of the same release (that is, if there's a
module made available, it should work with 2.2.n, 2.2.n+1,
2.2.n+2, ... 2.2.m where n is the first PIAT version of 2.2
and m is the last), in other words, users aren't forced to
upgrade the core just to get a library updated _unless_ the
update to the library actually relies on a _bug fix_ in the
core.
But as I'm not a Python-in-a-Tie member, I'll let them respond
authoritatively,
Mike

You could change that <wink>. Get ready to be suggested for the
job of 'official spokesman' as well, since you have just demonstrated
competance for the position <grin> ....

was-that-the-roadrunner-I-just-saw-zipping-away-to-the-horizon-or 'ly
Laura Creighton

[Mike C. Fletcher]

I just sent off the membership request. As for "official
spokes-person"; it might seem strange for the official spokes-person for
the business side of Python to be someone who's currently neither an
employee nor an owner of any business (of course, you could change that
;) ).

Meep, meep, zoom,
Mike

Post by Laura Creighton

Post by Mike C. Fletcher
But as I'm not a Python-in-a-Tie member, I'll let them respond
authoritatively,
Mike

You could change that <wink>. Get ready to be suggested for the
job of 'official spokesman' as well, since you have just demonstrated
competance for the position <grin> ....
was-that-the-roadrunner-I-just-saw-zipping-away-to-the-horizon-or 'ly
Laura Creighton

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Laura Creighton]

Post by Mike C. Fletcher
I just sent off the membership request. As for "official
spokes-person"; it might seem strange for the official spokes-person for
the business side of Python to be someone who's currently neither an
employee nor an owner of any business (of course, you could change that
;) ).
Meep, meep, zoom,
Mike

Cool. These things take about 3 weeks to get approved, but, (don't
tell anybody) you are in. Now, was that a hint that you would like
a job? Doing what? where?

Laura

[Mike C. Fletcher]

Since you ask ;) ... I'll travel for short and mid-length contracts (up
to 6 months or so), but I like living in Toronto on the whole, so
permanent relocation isn't really something I'm looking for. As to
what, I'm flexible; I like challenges, I prefer cross-disciplinary
problems, and I like working in small groups.

You mention being in Toronto to kick Peter (and visit some other
people), does that mean we'll be seeing you at the PyGTA meeting this
evening?

Ex-Torontonians-get-in-for-half-price-but-then-we-make-them-work-ly 'yrs,
Mike

Post by Laura Creighton

Post by Mike C. Fletcher
I just sent off the membership request. As for "official
spokes-person"; it might seem strange for the official spokes-person for
the business side of Python to be someone who's currently neither an
employee nor an owner of any business (of course, you could change that
;) ).
Meep, meep, zoom,
Mike

Cool. These things take about 3 weeks to get approved, but, (don't
tell anybody) you are in. Now, was that a hint that you would like
a job? Doing what? where?
Laura

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Laura Creighton]

Post by Mike C. Fletcher
Since you ask ;) ... I'll travel for short and mid-length contracts (up
to 6 months or so), but I like living in Toronto on the whole, so
permanent relocation isn't really something I'm looking for. As to
what, I'm flexible; I like challenges, I prefer cross-disciplinary
problems, and I like working in small groups.
You mention being in Toronto to kick Peter (and visit some other
people), does that mean we'll be seeing you at the PyGTA meeting this
evening?

Not unless Guido has lent you the keys to the Time Machine, or you
have invented the teleporter. (He won't lend me the keys, because
he is afraid I might go back and yank out the lambda). However, I
just got off the phone to my parents and they want to see me before
March ...

Post by Mike C. Fletcher
Ex-Torontonians-get-in-for-half-price-but-then-we-make-them-work-ly 'yrs,
Mike

Does-UofT-alumni-count-though-my-heart-still-resides-in-Nova-Scotia?-ly 'yrs

Laura

[Mike C. Fletcher]

We extend the offer to all people who have escaped ;) Toronto,
regardless of their official place of heart-registration.

I lost my Time Machine priveliges a few years (or a few decades) ago
(depending on the subjective timeline you want to use) when one of me
apparently went back to try and introduce Stackless' (the previous
version) micro-threading into Core-Python. So I suppose we'll have to
wait 'til March.

Though, if the PSU's teleporter is avail...

Laura Creighton wrote:
...

Post by Laura Creighton

Post by Mike C. Fletcher
You mention being in Toronto to kick Peter (and visit some other
people), does that mean we'll be seeing you at the PyGTA meeting this
evening?

Not unless Guido has lent you the keys to the Time Machine, or you
have invented the teleporter. (He won't lend me the keys, because
he is afraid I might go back and yank out the lambda). However, I
just got off the phone to my parents and they want to see me before
March ...

Post by Mike C. Fletcher
Ex-Torontonians-get-in-for-half-price-but-then-we-make-them-work-ly 'yrs,
Mike

Does-UofT-alumni-count-though-my-heart-still-resides-in-Nova-Scotia?-ly 'yrs
Laura

[Laura Creighton]

Post by Jeremy Hylton
So what's the word on Python in a Tie?
I thought I understood the original motivation to be that Python
development was moving too quickly, and business people needed a more
stable release without all the new features. But maybe I
misunderstood.

That is a pretty good summary.

Post by Jeremy Hylton
It sounds like PIAT users are just like all other Python users: "We
think the developers are adding too many new features and they should
stop -- except for these features, which we really need." <0.2 wink>
What would the difference, then, be between PIAT and Python 2.3?

Right now the shortage is in finding people who want anything enough
to want to do some work. (There is no shortage of people who think that
thing X would be great as long as somebody else does the work.) I
never envisioned backporting so many things, but if somebody wants to
work that hard, I won't tell them they cannot.

I think there is a compelling business case to put fixedpoint in the PIT,
but so far I don't think there is a compelling reason for the rest. This
is because I am completely ignorant and haven't heard any reasons at all,
not because I am completely knowledgeable and have my mind made up. So,
listening to people who want things, even if they don't want them enough
to work at making them happen is still very interesting to me.

Laura

Post by Jeremy Hylton
Jeremy
--
http://mail.python.org/mailman/listinfo/python-list

[Tim Peters]

[Laura Creighton]

Post by Laura Creighton
...
Right now the shortage is in finding people who want anything enough
to want to do some work. (There is no shortage of people who think
that thing X would be great as long as somebody else does the work.)

Those may be more timeless conditions than "right now" implies <wink>.

Post by Laura Creighton
...
I think there is a compelling business case to put fixedpoint in the PIT,

Curiously, that one wasn't in Mike's list. Doug Fort spun off a SourceForge
project to keep FixedPoint alive, and Guido approved the idea of folding it
into 2.3, and there it sits. If someone cares to volunteer the work for
that, I think it would be a good idea.

Post by Laura Creighton
but so far I don't think there is a compelling reason for the rest.
This is because I am completely ignorant and haven't heard any reasons
at all, not because I am completely knowledgeable and have my mind
made up. So, listening to people who want things, even if they don't
want them enough to work at making them happen is still very
interesting to me.

Me too. The problem is, as Jeremy said, if you listen to everyone, you'll
soon get votes for the union of all changes. The thing is, that for every
change made so far, someone *did* care enough to do the work.

Note that a datetime module is scheduled for inclusion in Python 2.3 too.
That hasn't been visible in the Python world because it still lives in the
CVS sandbox. I expect you'll get lots of votes for that too.

[Laura Creighton]

Thank you for the input, Peter:

/begin NAG

Join the PBF!

/end nag

Laura

Post by Laura Creighton

Post by Jeremy Hylton
What would the difference, then, be between PIAT and Python 2.3?

Right now the shortage is in finding people who want anything enough
to want to do some work. (There is no shortage of people who think that
thing X would be great as long as somebody else does the work.) I
never envisioned backporting so many things, but if somebody wants to
work that hard, I won't tell them they cannot.
I think there is a compelling business case to put fixedpoint in the PIT,
but so far I don't think there is a compelling reason for the rest. This
is because I am completely ignorant and haven't heard any reasons at all,
not because I am completely knowledgeable and have my mind made up. So,
listening to people who want things, even if they don't want them enough
to work at making them happen is still very interesting to me.

Logging would be nice, but I see no reason we couldn't (when *we*
get the time to put that in our stuff at all) just download it
and put it on top of our own Python installation.
Bool is another YES, although we're getting along fine just redefining
our standard (true,false) = (1,0) to be (True, False) = (1,0)
everywhere...
I agree with the fixedpoint comment in general, and we would in fact
probably use it within the next year.
And no, we definitely don't have time to do the work related to these
ourselves, yet... as I hinted, we don't even have time to *use* this
stuff even if it were available already... sigh. (I do seriously
hope to contribute back some of our advances related to the testing
framework though.)
-Peter
--
http://mail.python.org/mailman/listinfo/python-list

[Laura Creighton]

Skip> Perhaps the PBF could serve as a broker between companies with no
Skip> time and a bit of money and independent consultants with no money
Skip> and a bit of time to get some of this work done.
Laura> Want to run such a SIG, Skip?
I think I knew what your response would be before I made the suggestion. ;-)
I am currently not really in either camp, having just started at a job with
essentially no Python involvement, so I'm unlikely to be a good candidate to
coordinate such an activity.
Skip

Rats. I've got a whole escrow system planned out that would be great for
this, and connections to the Public Software Foundation
http://web.public-software.org/ which lets Americans get tax breaks for
providing money so that others can develop Open Source solutions.

But I also am on the board of directors of one startup, about to join
the board of another, and have a really nasty lawsuit happening all at
the same time. I'd really like to help somebody to do exactly as Skip
suggests, but I _cannnot_ run it myself. Not enough hours in the day
problem.

Does anybody else want to do this?

Laura

[Laura Creighton]

Post by Tim Peters
Curiously, that one wasn't in Mike's list. Doug Fort spun off a SourceForg

e

Post by Tim Peters
project to keep FixedPoint alive, and Guido approved the idea of folding it
into 2.3, and there it sits. If someone cares to volunteer the work for
that, I think it would be a good idea.

I have applied for membership in the PBF, and I hope I can work on
FixedPoint with them.

And we just approved the membership. cheer.

Laura Creighton

--
Doug Fort, Programmer
http://www.dougfort.net
--
http://mail.python.org/mailman/listinfo/python-list