what makes a good enhancement?

[Martin von Loewis]

Grant Griffin <not.this at seebelow.org> writes:

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

Note that much of this is or ought to be covered in PEP 5. So if you
find any significant aspects missing in PEP 5, I recommend to contact
the author of this PEP (Paul Prescod), and/or put a patch to this PEP
onto SF.

> - Is fully backwards compatible (e.g. a new library module).

No patch is full backwards compatible. If you add a new module, say,
x5673, then the code

try:
  import x5673
except ImportError:
  print "PASS"
else:
  print "FAIL"

would fail after the addition of the new module.

Instead, a PEP should clearly identify all aspects of backwards
incompatibility that it will necessarily introduce. It is then up to
the judgement of the reader whether these changes are serious or not.

> - Speeds Python in some significant way (e.g. xreadlines).

There have been cases in the past where such changes where rejected,
since the implementation resulted in a loss of clarity. Also,
improving the speed of Python without enhancing the language or its
libraries are better than changes that do extend/enhance: With such a
change, all existing code suffering from the speed deficiency must be
updated to use the new API, which then causes a
backwards-compatibility problem in case the code needs to work on
different Python versions.

> - Makes Python somehow easier to learn and/or use (e.g. unifying long integers
> and integers).

There is always a danger that such a change violates TOOWTDI, see the
recent discussion on making copy and len methods.

> Intolerable aspects:
> - Slows Python in any way.

By that rule, a number of recent (and not-so-recent) enhancements to
Python should have been rejected (e.g. rich comparisons). Usually,
implementing a feature initially will result in a speed drop for some
applications, unless the intent is specifically to improve the speed,
and can be shown to do so in all cases.

> - (However, one
> continues to doubt that any number of __future__ statments can ever make Python
> wart-free <wink>.)

I couldn't agree more - all those should have used the directive
keyword from the beginning :-)

Regards,
Martin