On Mon, Nov 24, 2014 at 3:23 AM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney <ben+pyt...@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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
