Modules for inclusion in standard library?

[Reinhold Birkenfeld]

Hello,

at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.

Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?

For my part, ctypes seems like a suggestion to start with.

Reinhold

 

[Thomas Heller]

Hello,

at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.

I have never used the path module before, although I've heard good
things about it. But, it seems to have problems with unicode pathnames,
at least on windows:

C:\>mkdir späm

C:\späm>py24
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\TSS5\components\_Pythonlib\path.py", line 97, in getcwd
return path(os.getcwd())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 5: ordinal not in range(128)
Although it seems this could be fixed by adding this constructor to the
path class:

def __new__(cls, init=u""):
if isinstance(init, unicode):
return _base.__new__(cls, init)
return _base.__new__(cls, init, sys.getfilesystemencoding())

I would really appreciate if Python's unicode support would be better
;-), and maybe it's easier to add this to the path module than to
os.path.

Thomas

 

[Fredrik Johansson]

Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?

First of all, numeric/numarray, obviously!

I'd also like to see wxPython, pygame and SciPy, but these may be too
heavy-weight. A good distribution system for widely used packages may
be a better solution than including everything in the standard
library.

For my part, ctypes seems like a suggestion to start with.

I think ctypes simply *must* go in there sooner later. My experience
dealing with binary data in Python is that it's a pain in the neck
compared to C, and the more machine-like behaviour and elegant code
you want, the slower it gets. I have refrained from using ctypes for a
number of reasons, but I would probably use it if it was in the
standard library.

-- Fredrik Johansson

 

[Steven Bethard]

For my part, ctypes seems like a suggestion to start with.

I believe this has been discussed somewhere before and the conclusion
was that ctypes should not be a candidate for inclusion in the Python
stdlib because people don't want things in the stdlib that can make
Python segfault.

STeVe

 

[Steven Bethard]

First of all, numeric/numarray, obviously!

There has been recent discussion about this. Check the python-dev list
archives I think. It's unlikely that all of numeric/numarray could go
into the Python stdlib because there still is disagreement between the
two camps as to the module architecture. However, there does seem to be
some agreement at the level of the basic array object, so it may be
possible that at least the array object itself might join the stdlib in
the not too distant future. I suspect there's more detailed discussion
of this in the numeric/numarray lists.

STeVe

 

[George Sakkis]

I'd love to see IPython replace the standard interpreter. Pychecker
seems to be a strong candidate too.

George

 

[Robert Kern]

Hello,

at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.

Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?

I would like to see the setuptools/PythonEggs/EasyInstall trifecta get
more attention and eyeballs. Once it is mature, I think that it will
obviate the desire for stdlibification of most of the packages being
requested here.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Michael Hoffman]

I would like to see the setuptools/PythonEggs/EasyInstall trifecta get
more attention and eyeballs. Once it is mature, I think that it will
obviate the desire for stdlibification of most of the packages being
requested here.

Looks pretty cool!

 

[Chris Connett]

pyparsing is the far and away the easiest general purpose parser out
there that I've encountered; BNF-style grammar parsing is a *pleasure*
with pyparsing. And it all comes in a single pure python module to
boot.

 

[projecktzero]

I'll 2nd the vote for Pychecker.

 

[bruno modulix]

I'd love to see IPython replace the standard interpreter.

I dont.

 

[George Sakkis]

I dont.

Care to say why ?

George

 

[John Roth]

Hello,

at the moment python-dev is discussing including Jason Orendorff's path
module
into the standard library.

Do you have any other good and valued Python modules that you would think
are
bug-free, mature (that includes a long release distance) and useful enough
to
be granted a place in the stdlib?

For my part, ctypes seems like a suggestion to start with.

Reinhold

I'd go with path. While I'm not at all certain that it's "the" way
to go, it'll at least break the conceptual logjam caused by simply
providing wrappers around the C library functions.

I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.

PyChecker, rather obviously. Likewise I'd like to see something
that would do a decent job of coverage analysis. Neither of the
modules out there at the moment is ready for prime time.

I don't have enough experience with interactive mode to have
an opinion on IPython. What I would like to see is a Python
based shell that could compete with either ksh or Monad.

John Roth

 

[Paul Rubin]

Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?

How about the win32 shell extension that allows stuff like reading
the registry? I'm not sure if that's the same as win32com.shell.

 

[Reinhold Birkenfeld]

Care to say why ?

For an easy, quick interactive interpreter, it's way to overloaded
with functions and too slow in startup.

However, having ipython in the Python distribution is worth a thought.

Reinhold

 

[George Sakkis]

For an easy, quick interactive interpreter, it's way to overloaded
with functions and too slow in startup.

Too slow ? It doesn't take more than a second or two to startup in a
two years old 1.8Ghz Athlon and an older 900Mhz sparcv9 I usually work
on. How slow is it at platforms you have experience with ?

However, having ipython in the Python distribution is worth a thought.

Reinhold

George

 

[Robert Kern]

Too slow ? It doesn't take more than a second or two to startup in a
two years old 1.8Ghz Athlon and an older 900Mhz sparcv9 I usually work
on. How slow is it at platforms you have experience with ?

I think that it loads up too much stuff to be the default interpreter,
speed issues aside. Sometimes, you really need to debug something that
requires you to control the imports.

It's a moot point anyways. The current ipython codebase isn't in any
shape to go into the stdlib, and the rewrite hasn't quite begun, yet.
Ask again in a year or two.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Simon Brunning]

I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.

I'm not sure that it would. Ctypes allows you, as one colleague
memorably put it, to "poke the operating system with a stick". You are
always going to be able to use ctypes to provoke spectacular crashes
of the kind that you can never get with 'ordinary' Python.

Having said that, I'd like to see ctypes in the standard library
anyway, with a suitably intimidating warning in the docs about the
trouble you can get yourself into with it.

 

[Thomas Heller]

I'm not sure that it would. Ctypes allows you, as one colleague
memorably put it, to "poke the operating system with a stick". You are
always going to be able to use ctypes to provoke spectacular crashes
of the kind that you can never get with 'ordinary' Python.
Right.

Having said that, I'd like to see ctypes in the standard library
anyway, with a suitably intimidating warning in the docs about the
trouble you can get yourself into with it.

To me, this sounds that *at least* a PEP would be needed to convince
Guido. Or, to record the reasoning why it cannot be included.

Thomas

 

[=?ISO-8859-1?Q?Gregory_Pi=F1ero?=]

I'd like to see some database API's to the most common databases
included. It would make Python much more useful for web development.
I've come across situations where a web host supports python and
supports MySQL yet it's taken me days to get the MySQLAPI installed
with running setup in my home directory etc. And I don't know what
options you have if you don't have shell access?

It definately seems to me that some API's to popular database would be
conducive to a "batteries included" approach.

-Greg