Python evolution: Unease

[Alex Martelli]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
   ...
> > GUI/IDEs for Python, 
> 
> I remember there was a gud interface for Python but it didn't work
> pretty well.  There's also IDLE which is pretty crude and flaky.  I
> think I'll just wait for Pypy deployment before worrying about this
> situation too much.  Is there something else I can download?

eric3 seems pretty good.


> > Python add-ons such as numarray,
> > gmpy, ctypes, ...) -- all of those you still have to download and
> > install, just as you would for the satanware.
> 
> That's unfortunate, that stuff should be included with Python.

numarray aims to be, WHEN they will be sufficiently complete and stable.
As for predictions of when that will be, I'm not qualified to offer one.

I think ctypes would be a _great_ addition to the standard Python
library in 2.5, if Thomas Heller agrees.

gmpy is LGPL (because so is the GMP library that gmpy wraps and
extends), so that including it with the standard Python library is very
iffy/problematic.  As gmpy's author I'd be delighted to do anything
possible to help this happen, but it just doesn't seem likely.  Besides,
I wonder how large a fraction of Python's user base really needs
something as specialized as gmpy -- unlimited-precision integers which
are _slightly_ faster than Python 2.4's built-in longs and offer a few
more highly specialized functions, etc.

Even if all of these were included in Python 2.5, how long will it be
before standard distributions and operating systems start including 2.5?

I don't agree with your general stance that the standard Python
distribution should be "sumo", including _everything_ that could
possibly be of _some_ interest to _some_ Python users, or thereabouts.
"Sumo distributions" have their place; enthought currently makes an
excellent one for scientific use of Python on Windows, and, I hear, it
is planning a similar one for Macintosh.  But the vast majority of
what's in it will be of no interest to somebody who doesn't care for
scientific applications -- and it will STILL be missing something that
some scientific users might like, such as gmpy.

Moreover, it's important to distinguish between standard Python, and
enriched distributions made of components that grow and change at
different speeds and with different groups of maintainers -- just the
same important distinction that must be drawn between Linux, and any of
the many distributions based on and including Linux.  Asking standard
Python to include dozens of third-party modules is just as silly as
asking the Linux kernel to be distributed with, say, gimp... anybody's
free to make a distribution including several components, but it's best
for the various components, including the core ones, to stay separate.


Alex