Rocco Moretti wrote: >>> 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.)
There are several degrees of std-ness for Python Modules: Example expat: The sources for this extension module are contained in the Python tarball, so this module is guaranteed to be part of a Python distribution Example zlib: If the include files and libs can be found, this extension will be built. So it's part of std-Python (the source), but not part of std-Python (installed). See others in Modules/Setup Binary distributions may choose additional modules which appear to be standard. Example: zlib is part of all Python-Installations on Windows and most Linux-distribution will have readlines as 'standard'. There seems to be a great reluctance by the Python developers to add modules of the expat kind, as this means responsibilities for additional source modules. There's also the problem with incompatible licenses, integrating a second configure, deciding when to update to the latest version of the library etc. Another problem is that there are often several modules for a specific problem (e.g. several modules interfacing to PostgreSQL), so there's always a chance to make an anemy for life, no matter which you pick. And module authors might not be interested as they'd be then bound by the Python release cycle. Daniel -- http://mail.python.org/mailman/listinfo/python-list
