Modules for inclusion in standard library?

[bruno modulix]

Care to say why ?

Sorry...

it was about the "replace", not about IPython itself nor about IPython
becoming part of the stdlib.

IPython is a great *advanced* REPL, but most of the time, I just don't
need its advanced features (I usually run the REPL as an emacs
subprocess), and moreover, beginners already have enough to learn !-)

regards

 

[Paul Rubin]

I'd like to see some database API's to the most common databases
included.

Yes, certainly, this is a serious deficiency with Python.

 

[Rocco Moretti]

Yes, certainly, this is a serious deficiency with Python.

Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the standard
libary should all be usable for anyone with a default OS + Python install.)

A notable exception is the dbm modules, but I seem to recall hearing
that the official position is that it was a mistake. (Now only kept for
backward compatability.)

 

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

While that policy does make sense, I think a database program falls
somewhere in between an OS and an everyday third party program. For
web developers, the database might as well be the OS. I use the
database to store everything in my web app. That way I can just worry
about 1 place to access information and not have to fool with files
and other OS issues.

So I humbly suggest the policy should be :

Python will not include interface code for third party programs which
are not part of an operating system or database system.

...
But I have no experience in designing world class programming
langauges so forgive me if I am too bold.

-Greg

 

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

And 1 more argument for adding DB support, a large part of PHP's
success as a web langauge is being easily interoperable with MySQL
(out of the box I think? I haven't used it.) But I think it's tight
integration with MySQL really helped it find its niche.

I think "batteries included" means Python MUST be useful for common
tasks right out of the box. Perhaps the only debate should be, what
are the most common tasks?

Just some more ideas to consider...

Greg

While that policy does make sense, I think a database program falls
somewhere in between an OS and an everyday third party program. For
web developers, the database might as well be the OS. I use the
database to store everything in my web app. That way I can just worry
about 1 place to access information and not have to fool with files
and other OS issues.

So I humbly suggest the policy should be :

Python will not include interface code for third party programs which
are not part of an operating system or database system.

..
But I have no experience in designing world class programming
langauges so forgive me if I am too bold.

-Greg

 

[Noah]

unzip() -- Not really a module, but a standard library function.
Why isn't it in the standard library?
It seems like I'm always adding it to my code.
I think I once heard an argument against it, but I forget what it was.
And yet I still find myself wanting unzip.

def unzip(list):
if len(list) == 0: return ()
l = []
for t in range(len(list[0])):
l.append(map( lambda x,t=t: x[t], list ))
return tuple(l)

Yours,
Noah

 

[Paul Rubin]

Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be usable for anyone with a default OS +
Python install.)

I've never heard of Python having such a policy and I don't understand
how such a stupid policy could be considered compatible with a
proclaimed "batteries included" philosophy. Why would Python
advocates want to make Python deliberately uncompetitive with PHP,
Java, and other languages that do include database modules?

A notable exception is the dbm modules, but I seem to recall hearing
that the official position is that it was a mistake. (Now only kept
for backward compatability.)

Ahem: Tkinter. There's actually several more, looking in the lib docs.

 

[Christopher Arndt]

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?

Hmmm, let's look into <pythonlib>/site-packackes, That's what I always
have installed:

- pysqlite
- Numeric
- PIL
- mxExtensions (mostly for mxDateTime)
- ClientForm
- ClientCookie
- pycrypto

Most of these are probably not elegible due to license issues but I'd
love to see SQLite support added to Python-out-of-the-box.

Also, when on windows, I always install the ActiveState distro because
it comes with the win23 extensions and more useful documentation. Maybe
there should be rather a separate "add-on-packs" distribution?

I think, this would be mostly useful for developers though. With
solutions like p2exe and python eggs becoming more widely used, caring
about what is installed and what not, shouldn't be such an issue anymore.

Chris

 

[Steven Bethard]

def unzip(list):
if len(list) == 0: return ()
l = []
for t in range(len(list[0])):
l.append(map( lambda x,t=t: x[t], list ))
return tuple(l)

The simplest solution to this problem that I know of:

def unzip(iterable):
return zip(*iterable)

However, Guido feels that this is an abuse of the argument passing
machinery. For a version that is a little more careful in the case of
iterables, see:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302325

STeVe

 

[Mike Meyer]

Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be usable for anyone with a default OS +
Python install.)

A notable exception is the dbm modules, but I seem to recall hearing
that the official position is that it was a mistake. (Now only kept
for backward compatability.)

Um - dbm is bundled with both os's I use (FreeBSD and OS X). I'd be
surprised if some variant or another didn't come standard on most
Linux systems as well.

Not all builtin functions are available on all os's. And the source
tree certainly includes modules that are specific to a single
operating systems (just look in the PC and Mac directories). I'm
pretty sure there are other modules that aren't supported on various
oddball systems - like termios.

Why should a module that's usable out-of-the-box on a fair variety of
systems be excluded just because it's not usable on all platforms?

<mike

 

[Terry Hancock]

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.

Gosh, I didn't know or care about ctypes, but now I'm interested! ;-D

 

[Simon Brunning]

(snip)

Most of these are probably not elegible due to license issues but I'd
love to see SQLite support added to Python-out-of-the-box.

Adding sqllite to the standard library has been discussed before:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/fd150297c201f814

 

[Simon Brunning]

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.

I have a feeling that Guido won't allow ctypes into the standard
library since it can crash Python. I don't know about you, but that's
I interpret this -
<http://mail.python.org/pipermail/python-dev/2004-January/041856.html>.

I am prepared to be wrong, though. Only Tim can channel Guido!

 

[Harry George]

I've never heard of Python having such a policy and I don't understand
how such a stupid policy could be considered compatible with a
proclaimed "batteries included" philosophy. Why would Python
advocates want to make Python deliberately uncompetitive with PHP,
Java, and other languages that do include database modules?


Ahem: Tkinter. There's actually several more, looking in the lib docs.

I typically install dozens of python packages (on IRIX, Solaris, AIX,
Linux, Win2K). 21 are standalone enough to be considered for the std
library. However I wouldn't necessarily want them in there, because:

a) They have their own release cycles, and coordinating would be too
painful. We'd get a Python-1.2.3 with a package ABC-2.3.4 which is
(too late) discovered to have a bug. So everyone would have to
download ABC-2.3.5 and install it anyway.

b) Installing distutils-aware python packages is trivial. I'd rather
the energy which might go into a bigger std library go instead into
helping projects which don't have distutils-style builds.

 

[Christopher Arndt]

Adding sqllite to the standard library has been discussed before:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/fd150297c201f814

Yeah, but they didn't seem to have come to a conclusion then. Also,
pysqlite 2.x has had a final release now and is still fairly DB-API
compatible (at least is seems so by looking at the docs).

I might go to their mailing list and ask about the status.

Chris

 

[Tom Anderson]

I've never heard of Python having such a policy and I don't understand
how such a stupid policy could be considered compatible with a
proclaimed "batteries included" philosophy.

Agreed. If this is the policy, it should be reconsidered. It's silly.

tom

 

[Mike Meyer]

b) Installing distutils-aware python packages is trivial. I'd rather
the energy which might go into a bigger std library go instead into
helping projects which don't have distutils-style builds.

How about integrating distutils and PyPI, so that distutils can
automatically download and install packages that are required by the
package it's currently installing? In other words, C-Python-AN.

<mike

 

[Robert Kern]

How about integrating distutils and PyPI, so that distutils can
automatically download and install packages that are required by the
package it's currently installing? In other words, C-Python-AN.

http://peak.telecommunity.com/DevCenter/EasyInstall

--
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

 

[Max M]

Hello,

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.

ctypes certainly. Even though it can crash Python. People using ctypes
would be aware of this.

Another good bet is BeautifulSoup, which is absolutely great for
scraping content from webpages.

http://crummy.com/software/BeautifulSoup/index.html


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[Ivan Van Laningham]

Hi All--

Another good bet is BeautifulSoup, which is absolutely great for
scraping content from webpages.

http://crummy.com/software/BeautifulSoup/index.html

Not if you want to handle HTML in anything but ASCII. BeautifulSoup
insists you change your site.py to change the default encoding if you
want to use non-ASCII. It might work beautifully, but I won't use it,
at least not until it's fixed to understand encodings.

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours