[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt,, idlever.py,,

Anthony Baxter anthony at interlink.com.au
Sat Mar 12 17:23:43 CET 2005

On Sunday 13 March 2005 01:19, "Martin v. Löwis" wrote:
> Kurt B. Kaiser wrote:
> > 1. Eliminating the separate IDLE versioning now that it's installed with
> >    Python when Tcl/Tk is available.
> > 2. Bringing its version in sync with Python 2.5.
> 3. Decouple Python and IDLE version numbers. I.e. IDLE version numbers
>     should change only when the IDLE maintainer thinks they should, not
>     when the Python release manager bumps the Python versions.

This is only a brief note here - I have a longer post coming on the subject
of uncoupled libraries in the Python core (triggered by Greg's recent Optik
post), but I doing mind any of the options above. I'm wondering if we
shouldn't have a centralised place in the CVS for these version numbers?

> For 2.4.1, the IDLE version number should just be rolled back (or
> forward) to "1.1.1". Unless you plan to include IDLE 1.1.2 with Python
> 2.4.2, it will stay at 1.1.1 in the 2.4 branch.
> Whether or not updating the IDLE code base to include new features
> is another issue - it might be that an exception can be made for IDLE;

I would be very strongly against this. If the code is distributed as part of
the stdlib, it should conform to the same rules as the rest of the stdlib. 

> OTOH, it might be reasonable to apply the same strict requirements
> for idlelib as we do for the rest of the Python library, i.e. no new
> features.

Exactly right. Expecting users to understand that "no new features, 
except for this or that or the other package" is unreasonable, particularly
when the delimiter is the (from a user's point of view) arbitrary distinction 
based on whether the source of the module is also separately available. 
See back to my earlier post of the subject of the rationale behind
no-new-features - if we're going to keep to this, we should do it right.

Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

More information about the Python-Dev mailing list