Not enough Python library development [was PEP scepticism]

phil hunt philh at comuno.freeserve.co.uk
Fri Jun 29 15:35:33 EDT 2001


On Fri, 29 Jun 2001 16:18:10 GMT, Guido van Rossum <guido at python.org> wrote:
>Roman Suzi <rnd at onego.ru> writes:
>
>> Is there a formal TODO list of the libraries and respective priorities?
>
>No, although there's a PEP for small feature requests (PEP 42).
>
>If you want to start making a list of missing libraries and submit a
>PEP, please do!  I'm sure many people will want to contribute.
>
>> For example, I think that some sort of standard GUI could help Python to
>> fight Java with it's Swing/AWT...
>
>This was tried many times -- there was even a GUI-sig with this goal.

I thought Tkinter was the standard GUI???

>Nothing ever came to fruition.  The problem is that designing and
>implementing a standard GUI that can compete with the existing
>offerings it an enormous amount of work,

Just a random idea: would it be possible to create a GUI with the
same python interface as Tkinter, but which talks to the KDE
or GNOME libraries instead? Or are their object models and internal
concepts too different -- e.g. in packing functionality?

> and folks always ran out of
>steam before they were even done with the requirements gathering.

My Parrot project has as one of its goals the ability to define
a gui (in a gui definition language) which can then be compiled
into source code for whatever language/library combination the
user desires. So there could be a python/tkinter output module,
a python/KDE one and a python/GNOME one. These would not be fully
compatible; a parrot class for output to Python/Tkinter would
require different functionality code than one for Python/KDE. But
it could be written in such a way that required changes are minimal.

(see <http://www.vision25.demon.co.uk/oss/parrot/intro.html> for details)

Parrot's not my top priority right now, but I expect I'll be making 
more changes to it later this year to bring it up to a workable state,

>> It could be also interesting to have time module as powerful as mxDateTime
>> in standard library. And so on.
>
>Well, propose one.  But what exactly is the point of adding it to the
>standard library when you can get mxDateTime if you need it?

Because Python should be "Batteries included". I wasn't aware mxDateTime
existed, and was semi-seriously thinking of writing a high-level
date/time library, with stuff like:

  d1 = dateToday()
  d2 = Date("1 Jan 1975")
  daysDifferent = d1 - d2

(you'd also be able to add/subtract time values, differences would 
be expressed in seconds, etc)

>I'd say
>your energy is better spent on reviving the catalog-sig (Python's
>CPAN-like effort, which needs new energy!)

I thought Vaults of Parnassus was for that?

-- 
## Philip Hunt ## philh at comuno.freeserve.co.uk ##







More information about the Python-list mailing list