[Python-Dev] rationale for the no-new-features approach

Anthony Baxter anthony at interlink.com.au
Wed Mar 9 13:17:06 CET 2005


So it's only fair that I write down my rationale for why I'm being anal
about the no-new-features approach. Comments are more than welcome -
ideally, after discussion, I'll put some more words in the bugfix PEP.

Goal 1: When we cut a bugfix release, people will upgrade to it.
  - This helps the users (they have bugs fixed)
  - This helps us (python-dev) because people won't be logging
    bugs against already-fixed-bugs.
  - This makes us (Python) look good, because people using 
    Python have the most bug-free experience possible.

Goal 2: Packagers of Python will package up releases of Python
            that are as close to the "official" release as possible.
  - This, to me, is a huge win. If we don't have to worry about 
    whether someone is running 2.4.1, or DistroFoo's version of 
    2.4.1 with a couple of backported fixes from 2.4.2, or some 
    other horrible frankenstein's monster of a release, it makes 
    our lives much easier. (This is also why I've been on a bit of
    a stomping exercise to attempt to get distros that broke Python
    into pieces to stop doing this (notably, Debian/Ubuntu's distutils-
    in-python-devel pain))
  - And yes, we're always going to have the problem of some distros
    stuck on old Python releases (Redhat -> Python 1.5.2, Debian stable
    -> Python 2.1, &c) but we can hopefully encourage them to at least 
    roll out the latest bugfix version of whatever version they're stuck on.

Goal 3: Good PR.
  - I've read a disturbing amount of words about other
    languages (*cough*Java*cough*) that have no sanity about
    minor and major releases. This seems to piss people off a
    great deal. One of Python's selling points is that we're very
    cautious and a suitable choice for grownups to use in business.
  - This is good for us (Python community) because it makes it
    less likely we'll be stuck in a job where we're forced to code 
    Perl, or C++, or Java, or some other horrible fate. It also boosts
    the size of the community, meaning that there will be more 
    volunteers to work on Python (hurrah!)

Goal 4: Try and prevent something like
            try:
                  True, False
            except NameError:
                  True, False = 1, 0
            from ever ever happening again. 
  - This, I hope, needs no further explanation <wink>

Anthony

-- 
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