Language change (was RE: iterators (was: python-dev summary))

[Donn Cave]

Quoth Raymond Hettinger <othello at javanet.com>:
| Courageous wrote: (quoting someone else)
|>| Anyway, my point is that there certainly are forces of change and
|>| "featurism", which come up squarely against one of Python's central
|>| features: its lack of central features.  (Ironic, ain't it? <wink>)
|>
|> :-)
|>
|> This is one of Python's true redeeming values; I hope and pray
|> that it doesn't get lost in the woods over the years.


| I absolutely agree that there should be a strong resistance toward
| creeping featurism, but think there should be an equally strong will
| to improve the language and not reject ideas out of hand.
|
| Examples of "good" directions for changes:
[... various perennial favorites ...]
| We can have language improvement without creeping featurism.

Right - let's pile on every "good" thing we can think of!

Changes like this aren't rejected "out of hand".  Per an early
post in this thread, the process may not always be any more rigorous
than the designer's hunch, but that hunch is what makes or breaks
the language.  If not everything has been accepted, I think the
reports of wholesale patch rejection could be a little deceiving,
depending on what all those rejected patches were actually proposing
to do.

But you can count on it, some of those changes you like will indeed
not be deemed worthy, and there doesn't need to be a reason that says
"this feature is actually bad, and here's what breaks".  Any change
is disruptive, any extra feature adds to the burden of learning and
using the language.  If you can't make a strong enough case for the
benefit of a new feature, then its value won't outweigh that burden.

Many of the notions you think are good directions aren't compelling
to me.  In fact they fall into several common classes of uncompelling:

1. "This will be easier for programmers who aren't programmers."
   - Who is the legitimate voice of this class of people?  Do you
     or anyone have evidence that your theories are going to pay
     off in practice?  Take the integer arithmetic thing - could
     there be a big can of worms waiting for the unwary user of
     the alternative, which I suppose would be floating point?
     If the innocent programmer is surprised by integer truncation,
     what about 1.0 != 1.0?
   - Are real programmers supposed to stick with Python as it sells
     them out?  Will a non-programmer constituency pan out for the
     new Python?  I overstate this as a conflict, but there is an
     element of that.  If the implication is that I should accept
     changes that are bad for me, because they're good for someone
     else who doesn't actually use Python and may never really have
     all that much use for any programming language, well, I'm not
     sure that makes total sense to me.
2. "This makes things more consistent."
   - Who cares?  Is Python's general level of inconsistency a big
     problem?  Some changes in that direction could conceivably make
     programming significantly more productive, but it has to be
     spelled out.  More consistent is not compelling per se.
3. "This alleviates awkwardness, kludginess, etc."
   - Who cares?  If we're talking about programming problems that
     really hurt at a software engineering level, for example force
     you to write the same thing in several places when you could
     have done it once given the feature, then that's interesting,
     but again, the onus is on the proponent to sell that.  The
     more usual case is that this "it's kludgy!" reaction is as
     vacuous is as it is emphatic.

Now I'm not saying the things you propose are altogether without
value, and I might even agree about one or two if I looked at it
hard enough.  The key is that the benefit must be clear and practical.

	Donn Cave, donn at oz.net
-------
| Examples of "good" directions for changes:
| -- change things that surprise uses (like unexpected integer math)
| -- change things that cause users to write awkward or kludgy code (like having
| to
|     set-up a loop counter when indexing over a list -- which PEP 234 proposes
|     to fix)
| -- change things that aren't polymorphic (like eval taking only dictionary
| objects
|     instead of general mapping objects and like the tuple.count() which GvR
| rejected).
| -- do tough things like unifying the type/class distinction (it will be a bear,
| but life
|     will be better afterwards).
| -- change difficult to use tools (like improving the debugger or adding
| interactive help).
| -- change things that prevent people from using their favorite tricks (like
| adding nested
|     scopes so that the functional programmers can go wild).
| -- implement things which improve performance (like xreadlines() or
| stacklessness).
| -- add more examples to the documentation