[Python-Dev] Re: Version Fatigue (was: Re: PEP 292, Simpler String Substitutions)

[François Pinard]

[Christian Tismer]

> >> """Version fatigue comes from the accumulated realization that most
> >> knowledge gained with regard to any particular version of a product   will
> >> be useless with regard to future generations of that same product."""
> >>
> >>Thinking about that and recent Python development:

> Guido van Rossum wrote:
> > This is highly exaggerated.

Exactly as stated, yes, I agree.

There is another kind of fatigue which may apply to Python, by which a
language becomes so featured over time that people may naturally come to
limit themselves to a sufficient subset of the language and be perfectly
happy, until they have to read the code written by guys speaking another
subset of the language possibilities.  Legibility becomes subjective and
questionable.  In the past, this has been true for some comprehensive
implementations of LISP, and as I heard (but did not experience) for PL/I.

There was a time, not so long ago, when there was only one way to do it
in Python, and this one way was the good way, necessarily.  This is not
true anymore, and we ought to recognise that this impacts legibility.

Fredrik wrote:

> Hey, don't lump generators in with the rest of the stuff.  Generators opens
> a new universe, the rest is more like moving the furniture around...

Indeed, there are very nice additions, that really bring something new,
and generators are of this kind.  Even moving the furniture around may be
very good, like for when the underlying mechanics get revised, acquiring
power and expressiveness on the road, while keeping the same surface aspect.
At least, people recognise the furniture, and could appreciate the new order.

Where it might hurt, however, is when the Python place get crowded with
furniture, that is, when Python gets new syntaxes and functions above those
which already exist, while keeping the old stuff around more or less forever
for compatibility reasons, with no firm intention or plan for deprecation,
and no tools to help users at switching from a paradigm to its replacement.
This ends up messy, as each programmer then uses some preferred subset.

The `$' PEP is a typical example of this.  Either the PEP should contain
a serious and detailed study about how `%' is going to become deprecated,
or the PEP should design `$' so nicely that it appears to be a born-twin of
the current `%' format, long lost then recently rediscovered.  The PEP should
convince us that it would be heart-breaking to separate so loving brothers.
Now, it looks like these two do not much belong to the same family, they
just randomly met in Python, they are not especially fit with one another.

Just the expression of a feeling, of course. :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard