PyWart: "Python's import statement and the history of external dependencies"
rosuav at gmail.com
Sun Nov 23 17:36:36 CET 2014
On Mon, Nov 24, 2014 at 3:23 AM, Dennis Lee Bieber
<wlfraed at ix.netcom.com> wrote:
> On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney <ben+python at benfinney.id.au>
> declaimed the following:
>> PostgreSQL is a full-blown system that is itself under continual
>> development, and its APIs continually change to match. Whatever Python
>> API for PostgreSQL gets put into the standard library today is likely
>> to be obsolete long before today's version of Python gets close to
>> ending support. That makes it a poor candidate for inclusion in the
>> standard library.
> I'd also consider that such a module is highly dependent upon having
> the related server available. If PostgreSQL access were to become a
> standard module I'd argue that the library should also include MySQL,
> Firebird/Interbase, M$ SQL Server, at a minimum.
I don't know how many ought to be included, but definitely MySQL would
be wanted. Including clients for proprietary protocols may be
considered less important. It would also be logical to include some of
the meta-protocols, though, like ODBC.
> SQLite3, as a file-server database, made sense as the actual database
> engine is accessed as part of the Python process when invoked -- not
> something that had to be configured/administered at a system-wide level.
This is true, and I've seen plenty of explanations as to why SQLite3
but no other database. I just found it odd that, against the exclusion
of several modules which would be of significant value to a very
common Python use-case (namely, servers (eg web) that need back-end
databases) is the inclusion of something equally specific but less
commonly useful (.WAV file manipulation). But, that's what PyPI's for.
More information about the Python-list