what makes a good enhancement?

[Grant Griffin]

Hi Gang,

After submitting a PEP recently (PEP 265), I think I might have gained at least
a little insight into what makes a good Python enhancement.  (By "enhancement",
I mean a change or addition to Python's features, not a bug-fix.)  What I've
learned (or at least what I _think_ I've learned) doesn't seem to be written
down anywhere, so as a "service" to the community, I thought I'd try to codify
it here.  Please feel free to agree/disagree/modify (not that I can stop you
<wink>.)

Desirable aspects of an enhancement:

- Is fully backwards compatible (e.g. a new library module).
- Speeds Python in some significant way (e.g. xreadlines).
- Makes Python somehow easier to learn and/or use (e.g. unifying long integers
and integers).
- Removes warts (e.g. statically nested scoping.)  (However, one doubts that any
number of __future__ statments can ever make Python wart-free <wink>.)
- Generalizes some principle which already appears in Python in special-case
form (e.g. generators/iterators generalize xrange and xreadlines, I think?.)
- Embody Tim's "Python Zen" principles.

Undesired, but tolerable aspects:

- Not fully backwards compatible, but has a reasonable transition path via a
__future__ statement.
- Result in feature/code/test/doc bloat (which any new feature does, actually.)
- Caters to a special purpose or special application area.

Intolerable aspects:

- Incompatible, with no transition path.
- Slows Python in any way.
- Core changes that can be done equally well in Python.
- Makes small changes around the edges.  (Perhaps any small change of interest
has already been incorporated by now.)

Considering all this, I conclude:

- Library changes are preferable to core changes because they don't slow or
bloat the core.
- Adding libaries is preferable to changing old libraries because there are no
compatibility issues, and because that doesn't make Python books obsolete.
- New library modules will have to provide a significant "batteries included"
benefit to justify the bloat they cause in terms of code, tests, and docs. 
Therefore, they will have to solve some sort of general problem not previously
solved by the standard library.
- __future__ things are tolerable if they remove a wart.  (However, one
continues to doubt that any number of __future__ statments can ever make Python
wart-free <wink>.)
- Most changes to the core will therefore use a __future__ statement.

admittedly-not-as-psychic-as-tim-(nor-particularly
   -good-at-reading-tea-leaves-<wink>)-ly y'rs,

=g2

_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com