Python evolution: Unease

[Alex Martelli]

Iwan van der Kleyn <none at none.net> wrote:
   ...
> And I do sense (reading planet python/this newsgroup) a mindset or at
> least a tendency by the people who really matter in these discussion to
> keep on adding features to the syntax; to add "structure" to Python. My
> personal preference would be to leave the language alone for a while and
> to improve its infrastructure.

I happen to agree with this preference as stated here -- the time to
change the language is at 3.0 release time (say a few years from now).

It _is_, of course, perfectly sensible for Guido to start musing out
loud on the only major addition he really wants to make at that distant
time a few years from now, namely optional static typing -- it will be a
biggie when it comes, so it should not be sprung on us all by surprise;
the more (and the earlier) feedback comes to help him decide the exact
details of that addition, the merrier.

Meanwhile, over on python-dev, the discussion is on completing the
AST-branch (so the standard library may finally include a full
python-coded Python compiler when 2.5 is released, likely in 2006),
dealing (in distutils, mostly) with the fact that the Mac may use some
case-sensitive filesystems but its default one is case-preserving but
insensitive, issues with memory allocation strategies triggered by
Darwin's weird realloc behavior (a realloc there never shrinks an
allocation, eek), the best maintenance strategy for old FAQs, what
functionality is to be added to the zipfile module (e.g., removing files
from a zip archive), and the fix of a misspelling in the docs.

I kid you not: these are the threads going on today in the python-dev
list, where most of [the discussion about] Python's development really
takes place.  Not sure who you believe "really matter in these
discussion" (sic), but the discussants today included Guido van Rossum,
Tim Peters, Martin v. Loewis, and many others.  How one can possibly
infer from such raw data "a mindset or at least a tendency ... to keep
adding features to the syntax" is really hard to explain, at least for
me.  Almost invariably, the great majority of proposals to change the
language, most particularly the syntax, come on this list, fortunately,
since that leaves python-dev essentially free to keep focusing on the
huge nitty-gritty daily work of enhancing the implementation (and other
aspects of the infrastruture, such as the spelling of the docs...);
almost invariably, moreover, the great majority of such proposals come
from clueless or semi-clueless newbies or semi-newbies.

You appear to have taken the fact that Guido appears to want lot of
early discussion about his ideas on optional static typing, presumably
to help those ideas develop, and drawn from that tiny speck of 'fact'
the most absurdly extrapolated conclusions, totally and utterly ignoring
the overwhelming countervailing mass of facts and evidence that point
exactly in the opposite direction.

Of course, what YOU think should happen regarding the infrastructure,
and what the people who donate their time to actually make things happen
want, may be totally at odds.  For example, you appear to keenly want
one standard IDE to be blessed and receive all attention, one standard
web framework ditto, and so on, and so forth; most core developers, on
the other hand, appear to be very modestly inclined to spend their time
and energy in that direction, so that only a rather minor fraction of
the python-dev effort is channeled that way.  Innovative efforts are
best kept OUT of the core Python standard, many of us believe, as long
as their innovative fervor continues: once something does get into the
standard Python library &c, it won't and shouldn't develop very fast,
nor at all freely, due to the tiranny of backwards compatibility, cross
platform support, and the huge increase in maintenance/support efforts
that comes when something suddenly becomes much more widespread and
widely used than it previously used to be.  Enhancements in library
organization and functionality, fixing typos in the docs, or deciding
whether and how to work around some platform's quirks, are definitely
less glamorous than inventing new grand unification projects, but
nevertheless this kinds of things IS by far the vastest part of the work
in a large and mature open-source project.

Wonderfully innovative projects, *OUT* of the core language/library, are
very abundant.  Come to PyCon in March and you'll probably hear several
eye-opening, possibly mind-boggling talks about such things as the type
inferencing and optimizations of the pypy project, or Enthought's
breathtaking Traits and Envisage technologies -- all "infrastructure",
btw, no language changes involved.  It's perfectly fit and proper that
such work takes place exactly where it's taking place now.  If and when
it matures and stabilizes, to the point of not needing any more
innovation but rather consolidation and spreading, _then_ some part of
it may be merged into the standard core.  Many people contributing to
such innovative projects are also Python core committers, of course.


Alex