Paul Rubin <http://[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list