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