[Python-ideas] Official MySQL module

[Thomas Allen]

Hi, there! Do you plan to add an official module for connecting to MySQL databases? Existing third-party modules are bad-documented or no longer maintained... That's kinda strange, that such a nice language doesn't have it yet.

[Dustin J. Mitchell]

Where would such a module come from? The PSF can't wave a magic
"official" flag and will software into existence. Someone needs to
write it.

I suspect from your use of the term "third party", that you come from
the world of proprietary software. In OSS, we're all mutual third
parties.

There are several nice MySQL bindings out there. Just about everyone
uses Python-MySQL, but I've recently given my heart to PyMySQL, since
it's pure python and thus a lot easier to install. If I recall from
the SQLAlchemy docs, there are a few others out there. So I suspect
that your basic premise is incorrect: there's lots of good options out
there, and in fact several tools to abstract the differences between
them (SQLAlchemy being my choice). I don't think the community would
be well-served by selecting one as the default implementation.

Dustin
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas

[David Mertz]

I disagree moderately with Dustin.  Obviously, it is true that a magic wand doesn't produce a standard-library module.  However, having support for MySQL/MariaDB (and PostgreSQL) in the standard library would be desirable.  This would bring MySQL support to the same level as we have for SQLite3.

In particular, I would NOT WANT such standard library support to include any ORM layer to it; I feel like those should remain as third-party tools (and compete on their various merits).  But the basic level of providing a *binding* feels like something desirable (and specifically, a binding that was as close to a drop-in substitute for 'sqlite3' as possible).

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.

[Guido van Rossum]

On Thu, Mar 7, 2013 at 1:16 PM, David Mertz <me...@gnosis.cx> wrote:
> I disagree moderately with Dustin. Obviously, it is true that a magic wand
> doesn't produce a standard-library module. However, having support for
> MySQL/MariaDB (and PostgreSQL) in the standard library would be desirable.
> This would bring MySQL support to the same level as we have for SQLite3.
>
> In particular, I would NOT WANT such standard library support to include any
> ORM layer to it; I feel like those should remain as third-party tools (and
> compete on their various merits). But the basic level of providing a
> *binding* feels like something desirable (and specifically, a binding that
> was as close to a drop-in substitute for 'sqlite3' as possible).

Well, the model should be PEP 249 (db-API 2.0), not sqlite3.

--
--Guido van Rossum (python.org/~guido)

[Dustin J. Mitchell]

On Thu, Mar 7, 2013 at 4:16 PM, David Mertz <me...@gnosis.cx> wrote:
> I disagree moderately with Dustin. Obviously, it is true that a magic wand
> doesn't produce a standard-library module. However, having support for
> MySQL/MariaDB (and PostgreSQL) in the standard library would be desirable.
> This would bring MySQL support to the same level as we have for SQLite3.

Having a simple database engine in the stdlib is helpful -- it means
that apps like Buildbot can use a database without requiring users to
set up MySQL or Postgres. I think the Python community is actually
better served by having an ecosystem of competing DBAPI
implementations for other databases. If the stdlib blesses one, then
there's very little point in the others continuing to exist. Would
that be Python-MySQL (which is somewhat heavy and requires MySQL
libraries, and judging from the sourceforge page the project is
moribund and rudderless) or PyMySQL (which, much as I love it, is
somewhat less performant, probably buggier, and still lacks some
things you'd want for production use, like SO_KEEPALIVE).

> In particular, I would NOT WANT such standard library support to include any
> ORM layer to it; I feel like those should remain as third-party tools (and
> compete on their various merits). But the basic level of providing a
> *binding* feels like something desirable (and specifically, a binding that
> was as close to a drop-in substitute for 'sqlite3' as possible).

I didn't say anything about an ORM!

SQLAlchemy has a fantastic query-formulation layer ("core") that
manages to work around idiosyncracies with the various DBAPI
implementations out there, while not trying to map any objects or
relations. And as Guido says, any implementation -- in or out of the
stdlib -- is based on PEP249. SQLAlchemy just wraps that with some
syntax and compatibility hacks. Here's the list of supported
dialects:
http://docs.sqlalchemy.org/en/rel_0_8/dialects/

[Gregory P. Smith]

No database connector module should ever be part of the standard library unless that entire database is included as part of Python distributions.  MySQL isn't part of Python so all mysql connector modules belong as third party things (perhaps as part of mysql itself if they wanted to get their act together).

want sqlite?  we bundle it.  want something else?  you have to install something else separately so you have to install its connector module separately as well.

-gps

On Thu, Mar 7, 2013 at 12:41 PM, Thomas Allen <jsb...@gmail.com> wrote:

Hi, there! Do you plan to add an official module for connecting to MySQL databases? Existing third-party modules are bad-documented or no longer maintained... That's kinda strange, that such a nice language doesn't have it yet.

[David Mertz]

On Mar 7, 2013, at 2:00 PM, Gregory P. Smith wrote:
> No database connector module should ever be part of the standard library unless that entire database is included as part of Python distributions. MySQL isn't part of Python so all mysql connector modules belong as third party things (perhaps as part of mysql itself if they wanted to get their act together). want sqlite? we bundle it. want something else? you have to install something else separately so you have to install its connector module separately as well.

I think I'm convinced by Gregory here, and withdraw my previous opinion. It does feel strange to have a Python module in the standard "batteries-included" distribution simply do *nothing* if other software doesn't happen to be installed. Although, off the top of my head, 'webbrowser' is also exactly such a module (but one can argue that every end-user OS includes at least one such external tool, so it's a kind of "system service").

Obviously, as Guido points out, when I wrote 'sqlite3' I really meant 'db-API 2.0'. But I was just being concrete rather than abstract about it, since one is a module and the other a specification. I.e. it's conceivable that a program might change one line and work:

# import sqlite3 as mydb
import mysql as mydb

But there's no line in a Python program like:

import db_api20 as mydb

(well, at least two lines really, there's not way the '.connect()' can be DB-independent).

--
Dred Scott 1857; Santa Clara 1886; Plessy 1892; Korematsu 1944; Eldred 2003

[Eric V. Smith]

On 3/7/2013 4:16 PM, David Mertz wrote:
> I disagree moderately with Dustin. Obviously, it is true that a magic
> wand doesn't produce a standard-library module. However, having support
> for MySQL/MariaDB (and PostgreSQL) in the standard library would be
> desirable. This would bring MySQL support to the same level as we have
> for SQLite3.
>
> In particular, I would NOT WANT such standard library support to include
> any ORM layer to it; I feel like those should remain as third-party
> tools (and compete on their various merits). But the basic level of
> providing a *binding* feels like something desirable (and specifically,
> a binding that was as close to a drop-in substitute for 'sqlite3' as
> possible).

I agree with David on both points.

- Surely a MySQL binding is a battery we should consider including, if
an author were to offer it to us. I have no experience with them, so I
can't offer any advice on which is best.

- We don't want to include an ORM. It seems this space is still evolving
rapidly. At least, every time I upgrade SQLAlchemy (which I love) it
breaks some code.

Eric.

> Python...@python.org <mailto:Python...@python.org>

> http://mail.python.org/mailman/listinfo/python-ideas
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons. Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


--

Eric.

[Nick Coghlan]

On Fri, Mar 8, 2013 at 7:41 AM, Eric V. Smith <er...@trueblade.com> wrote:
> On 3/7/2013 4:16 PM, David Mertz wrote:
>> I disagree moderately with Dustin. Obviously, it is true that a magic
>> wand doesn't produce a standard-library module. However, having support
>> for MySQL/MariaDB (and PostgreSQL) in the standard library would be
>> desirable. This would bring MySQL support to the same level as we have
>> for SQLite3.
>>
>> In particular, I would NOT WANT such standard library support to include
>> any ORM layer to it; I feel like those should remain as third-party
>> tools (and compete on their various merits). But the basic level of
>> providing a *binding* feels like something desirable (and specifically,
>> a binding that was as close to a drop-in substitute for 'sqlite3' as
>> possible).
>
> I agree with David on both points.
>
> - Surely a MySQL binding is a battery we should consider including, if
> an author were to offer it to us. I have no experience with them, so I
> can't offer any advice on which is best.

We've learned the hard way that including database bindings in the
standard library is a bad idea, as development on those bindings needs
to be synchronised with the release cycle of the corresponding
database server, not the Python release cycle. The bsddb bindings in
Python 2 were a neverending source of trouble, which is why they were
booted out to PyPI for Python 3.

sqlite3 is different (and more appropriate for the standard library),
as it's a wrapper around a file format rather than a binding to an
active database server.

The number one question to ask about candidates for standard library
inclusion is "Does it make sense for this module to receive new
features only once every 18-24 months, and only when you upgrade to a
new version of Python?". Interfaces to specific external services
(including databases) almost never pass that test.

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Guido van Rossum]

On Thu, Mar 7, 2013 at 3:20 PM, Nick Coghlan <ncog...@gmail.com> wrote:
> On Fri, Mar 8, 2013 at 7:41 AM, Eric V. Smith <er...@trueblade.com> wrote:
>> On 3/7/2013 4:16 PM, David Mertz wrote:
>>> I disagree moderately with Dustin. Obviously, it is true that a magic
>>> wand doesn't produce a standard-library module. However, having support
>>> for MySQL/MariaDB (and PostgreSQL) in the standard library would be
>>> desirable. This would bring MySQL support to the same level as we have
>>> for SQLite3.
>>>
>>> In particular, I would NOT WANT such standard library support to include
>>> any ORM layer to it; I feel like those should remain as third-party
>>> tools (and compete on their various merits). But the basic level of
>>> providing a *binding* feels like something desirable (and specifically,
>>> a binding that was as close to a drop-in substitute for 'sqlite3' as
>>> possible).
>>
>> I agree with David on both points.
>>
>> - Surely a MySQL binding is a battery we should consider including, if
>> an author were to offer it to us. I have no experience with them, so I
>> can't offer any advice on which is best.
>
> We've learned the hard way that including database bindings in the
> standard library is a bad idea, as development on those bindings needs
> to be synchronised with the release cycle of the corresponding
> database server, not the Python release cycle. The bsddb bindings in
> Python 2 were a neverending source of trouble, which is why they were
> booted out to PyPI for Python 3.

Hm. It's true that bsddb was a neverending nightmare. But AFAIR that
was due to the bsddb C bindings changing regularly.

> sqlite3 is different (and more appropriate for the standard library),
> as it's a wrapper around a file format rather than a binding to an
> active database server.

Hardly. SQLite3 is probably as complex as bsddb. It is just better
maintaned, and its authors have an incredible dedication to backwards
compatibility at the C API level. (Watch this talk:
https://www.youtube.com/watch?v=jN_YdMdjVpU )

Honestly, I don't know what the status of the C bindings for MySQL is,
but it might well be similar. MySQL is a pretty mature product.

(And I don't agree with Greg P Smith's complete rejection of including
anything in the stdlib that we don't distribute. There are certainly
plenty of optional dependencies, from Tcl/Tk to GNU readline.)

> The number one question to ask about candidates for standard library
> inclusion is "Does it make sense for this module to receive new
> features only once every 18-24 months, and only when you upgrade to a
> new version of Python?". Interfaces to specific external services
> (including databases) almost never pass that test.

I wouldn't mind if someone looked into this in depth for MySQL and
Postgres. It's been a while since we last looked at this. If the
answer is different for MySQL than for Postgres that shouldn't stop us
from including one but not the other.

Agreed on the "no ORM in the stdlib" position.

--
--Guido van Rossum (python.org/~guido)

[M.-A. Lemburg]

On 08.03.2013 00:20, Nick Coghlan wrote:
> On Fri, Mar 8, 2013 at 7:41 AM, Eric V. Smith <er...@trueblade.com> wrote:
> The number one question to ask about candidates for standard library
> inclusion is "Does it make sense for this module to receive new
> features only once every 18-24 months, and only when you upgrade to a
> new version of Python?". Interfaces to specific external services
> (including databases) almost never pass that test.

Agreed.

The reason why we included sqlite support in the stdlib was
to have an easy to use and readily available Python DB-API 2.0
compatible database in Python, so that people can learn how
to use SQL databases, implement small projects with it and then
upgrade to one of the many client-server databases out there,
if they need to.

It serves that function well, esp. since most systems come
with SQLite pre-installed. On Windows, we even include SQLite
together with the Python installation.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Mar 07 2013)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/

[Eric V. Smith]

On 3/8/2013 3:06 AM, M.-A. Lemburg wrote:
> On 08.03.2013 00:20, Nick Coghlan wrote:
>> The number one question to ask about candidates for standard library
>> inclusion is "Does it make sense for this module to receive new
>> features only once every 18-24 months, and only when you upgrade to a
>> new version of Python?". Interfaces to specific external services
>> (including databases) almost never pass that test.
>
> Agreed.

I agree with this, too. However, I think this is a transient situation,
not a permanent one. It's entirely possible that there exists, or will
exist, a MySQL binding that meets this criteria. I don't know. But it
shouldn't preclude us considering a binding that meets the criteria.

As to Greg's point about not including a database binding that requires
other software to run, I disagree. It's client/server: do we really need
to include the server in order to supply the client? We include nntplib,
with no server. We include webbrowser, but no web browser. imaplib, but
no imap server. Etc.

--
Eric.

[Amaury Forgeot d'Arc]

2013/3/8 Eric V. Smith <er...@trueblade.com>

On 3/8/2013 3:06 AM, M.-A. Lemburg wrote:
> On 08.03.2013 00:20, Nick Coghlan wrote:

>> The number one question to ask about candidates for standard library
>> inclusion is "Does it make sense for this module to receive new
>> features only once every 18-24 months, and only when you upgrade to a
>> new version of Python?". Interfaces to specific external services
>> (including databases) almost never pass that test.
>
> Agreed.

I agree with this, too. However, I think this is a transient situation,
not a permanent one. It's entirely possible that there exists, or will
exist, a MySQL binding that meets this criteria. I don't know. But it
shouldn't preclude us considering a binding that meets the criteria.

As to Greg's point about not including a database binding that requires
other software to run, I disagree. It's client/server: do we really need
to include the server in order to supply the client? We include nntplib,
with no server. We include webbrowser, but no web browser. imaplib, but
no imap server. Etc.

Doesn't a MySQL binding have to link with some client library?  libmysql.so?

How is it licensed?

I found this page: http://www.mysql.com/about/legal/licensing/foss-exception/

which seems to prevent redistribution under non-free licenses.

--
Amaury Forgeot d'Arc

[Eric V. Smith]

On 3/8/2013 7:39 AM, Amaury Forgeot d'Arc wrote:
>
>
> 2013/3/8 Eric V. Smith <er...@trueblade.com <mailto:er...@trueblade.com>>

It's not true that a client library is required. PyMySQL is pure Python.
We could also write a C connection module ourselves, if needed.

Again, I'm not saying I know there's a library suitable for stdlib
inclusion, or that the time is right for such inclusion. I'm just
saying that it's possible, and I think it's desirable.

[Amaury Forgeot d'Arc]

2013/3/8 Eric V. Smith <er...@trueblade.com>

> Doesn't a MySQL binding have to link with some client library?  libmysql.so?

> How is it licensed?
> I found this
> page: http://www.mysql.com/about/legal/licensing/foss-exception/
> which seems to prevent redistribution under non-free licenses.

It's not true that a client library is required. PyMySQL is pure Python.
We could also write a C connection module ourselves, if needed.

Ah, MySQL TCP protocol is public and easy to implement. Good!

OTOH it probably makes it more difficult to use semi-advanced features.

Prepared statements, for example.

[Joao S. O. Bueno]

On 8 March 2013 08:01, Eric V. Smith <er...@trueblade.com> wrote:
> We include webbrowser, but no web browser. imaplib, but
> no imap server. Etc.

Picking only this point - becuase it highlights what is bothering me:
In my lectures, I use to justify Python not including (up to now)
bindings for MySQL or PostgreSQL , in contrast to offering
ways to interoperate with imap, http, and pop, because the former
are "products" and the later are "standards" - and it would not be
well for a language standard library to include "other's products" in
it (and yes, on my lecture I talked about this in contrast with PHP).

So, I do feel a bit uncomfortable with the idea of including bindings for
3rd party databases in the stdlib - but I think that is an emotional thing
only , and can easily be rationalized away with
"practicality beats purity" - and the mention somewhere else that
in Free Software environment, saying "3rd party" can be
misleading.

Regards,

js
-><-

[Guido van Rossum]

On Fri, Mar 8, 2013 at 6:07 AM, Joao S. O. Bueno <jsb...@python.org.br> wrote:
> On 8 March 2013 08:01, Eric V. Smith <er...@trueblade.com> wrote:
>> We include webbrowser, but no web browser. imaplib, but
>> no imap server. Etc.
>
>
> Picking only this point - becuase it highlights what is bothering me:
> In my lectures, I use to justify Python not including (up to now)
> bindings for MySQL or PostgreSQL , in contrast to offering
> ways to interoperate with imap, http, and pop, because the former
> are "products" and the later are "standards" - and it would not be
> well for a language standard library to include "other's products" in
> it (and yes, on my lecture I talked about this in contrast with PHP).

That sounds rather an idealized opinion, and not a very useful
attitude. Some "standards" represent commercial interests. The
"products" you mention are in fact well-respected open source
projects.

But anyway, Python's standard library (unlike GNU) does not have an ax
to grind about what software should or should not be supported from an
ethical perspective. It is all about what is useful to a large enough
number of Python users, and what is feasible given the available
volunteer power and the technical properties of the software in
question.

> So, I do feel a bit uncomfortable with the idea of including bindings for
> 3rd party databases in the stdlib - but I think that is an emotional thing
> only , and can easily be rationalized away with
> "practicality beats purity" - and the mention somewhere else that
> in Free Software environment, saying "3rd party" can be
> misleading.

I do not understand this last phrase.

--
--Guido van Rossum (python.org/~guido)

[Terry Reedy]

On 3/8/2013 12:45 PM, Guido van Rossum wrote:

> But anyway, Python's standard library (unlike GNU) does not have an ax
> to grind about what software should or should not be supported from an
> ethical perspective. It is all about what is useful to a large enough
> number of Python users, and what is feasible given the available
> volunteer power and the technical properties of the software in
> question.

Given that we have a growing list of open issues, now at 3800 (1600
behavior, 1200 enhancement*, 600 not selected (doc?), 400 other), I
think perhaps we are already beyond what the current volunteers can handle.

* I think the majority of these should either be closed or referred to
this list, as they are essentially dead without getting support here.

In any case, with Guido having said he is open to the possibility of a
mysql client module, and others having expressed opinions on the
abstract idea, pro and con, it seems to me that the next step is a
concrete proposal.

--
Terry Jan Reedy

[Éric Araujo]

Le 08/03/2013 09:07, Joao S. O. Bueno a écrit :
> the mention somewhere else that in Free Software
> environment, saying "3rd party" can be misleading.

In Python documentation and materials, we use that term to mean “not
included in the standard library”. The user is one party, the Python
distribution is another one, and modules that are not in the stdlib are
called “third-party modules” and available from sources such as PyPI. I
don’t think there’s more than that to it.

Regards

[Joao S. O. Bueno]

It does not amtter much - it is that I did not remember if it was in this thread
or in another list that someone wrote "in Open Source we don't usually
refer to other projects as 3rd party" (and it happened it was on another list).
Anyway, you just clarified exactly what I intended to mean above with

""" The "products" you mention are in fact well-respected open source
projects."""

All in all - the argument I cited on the grand-parent message was
something I build
in lectures to address PHP people querying about built-in
MySQL support - and I _do_ agree with "pratically beats purity" - or
as you expanded
it: """ Python's standard library (unlike GNU) does not have an ax

to grind about what software should or should not be supported from an
ethical perspective."""

Thanks for the response anyway.
Now..onto those PEPs :-)

(maybe someone would like to tackle writing CFFI based drivers
for PostgreSQL and MySQL? :-) )

js
-><-

[Greg Ewing]

Eric V. Smith wrote:
> It's client/server: do we really need
> to include the server in order to supply the client? We include nntplib,
> with no server. We include webbrowser, but no web browser. imaplib, but
> no imap server. Etc.

Those client modules are self-contained, though. Database
client modules usually rely on a C component that comes
with the database and gets updated on the database's
release schedule rather than Python's.

--
Greg

[Amaury Forgeot d'Arc]

2013/3/9 Greg Ewing <greg....@canterbury.ac.nz>

Eric V. Smith wrote:

It's client/server: do we really need
to include the server in order to supply the client? We include nntplib,
with no server. We include webbrowser, but no web browser. imaplib, but
no imap server. Etc.

Those client modules are self-contained, though. Database
client modules usually rely on a C component that comes
with the database and gets updated on the database's
release schedule rather than Python's.

Not with PyMySQL which directly implements the MySQL protocol,

on top of socket and ssl modules.

Not as nice a an official C API, though.

[Andrew Barnert]

On Mar 8, 2013, at 9:45, Guido van Rossum <gu...@python.org> wrote:

> On Fri, Mar 8, 2013 at 6:07 AM, Joao S. O. Bueno <jsb...@python.org.br> wrote:
>
>> So, I do feel a bit uncomfortable with the idea of including bindings for
>> 3rd party databases in the stdlib - but I think that is an emotional thing
>> only , and can easily be rationalized away with
>> "practicality beats purity" - and the mention somewhere else that
>> in Free Software environment, saying "3rd party" can be
>> misleading.
>
> I do not understand this last phrase.

Open source software isn't built by corporations for their own corporate interest, but by people for their own personal needs. The same people could be working on MySQL and Python, and there's positive synergy with no conflict of interest, and no implied exclusion of anyone outside the implicit partnership-of-one-person. This means there's no such word as "third party" in open source.

If this all sounds hand-wavy and hyperbolic and based on idealizations rather than reality, well, it's esr, what do you expect?

But there is some truth there. Apple isn't going to support MySQL without first talking bizdev with Oracle and the competition. Python isn't a company, and doesn't have to think that way. So, "third party" doesn't have quite the same implications.

[Stephen J. Turnbull]

Andrew Barnert writes:

> This means there's no such word as "third party" in open source.

The distinction remains useful. As pointed out earlier, there's the
user (first party), the project (second party), and the distributor(s)
(third party) of any modules that neither first nor second party
controls. The point of the distinction is that the user therefore
bears a risk that the second party's product will not work as the user
desires because of changes or bugs in the third party project. This
can be due to bugs the third party doesn't acknowledge, or because of
new features that the user wants/needs that the project doesn't
support.

True, that risk is mitigated in open source because the first two
parties have an additional option: one can *take* responsibility for a
third party module (by cooperating with the third party, for example),
or even take control (of a forked version). Nevertheless, the risk
remains.

I don't have an opinion on whether that risk is prohibitive for MySQL
(or PostgreSQL). But it is an important consideration, and the term
"third party" is a useful abbreviation for it.

BTW:

> Open source software isn't built by corporations for their own
> corporate interest, but by people for their own personal needs.

Nobody builds *open source* software. People (including corporate
"persons") build *software*, then maybe they release it as a
proprietary product, or as open source, or both.

The problem with corporations is that they have a fiduciary
responsibility to produce income for their owners, which often
overrides considerations of voluntary cooperation.

[Stefan Behnel]

Gregory P. Smith, 07.03.2013 23:00:

> No database connector module should ever be part of the standard library
> unless that entire database is included as part of Python distributions.
> MySQL isn't part of Python so all mysql connector modules belong as third
> party things (perhaps as part of mysql itself if they wanted to get their
> act together).
>
> want sqlite? we bundle it. want something else? you have to install
> something else separately so you have to install its connector module
> separately as well.

+1

I would also note that stdlib inclusion usually works the other way round:
someone, usually the author, has to commit to a) contribute the code and b)
maintain it in the stdlib, basically forever. While expressing the wish to
have something in the stdlib is ok, it's not really useful unless it makes
the "someone" above step up and sign that commitment.

Stefan

[Antoine Pitrou]

On Sat, 09 Mar 2013 16:56:04 +0900
"Stephen J. Turnbull" <ste...@xemacs.org>
wrote:

>
> > Open source software isn't built by corporations for their own
> > corporate interest, but by people for their own personal needs.
>
> Nobody builds *open source* software.

Well, of course we do. If Python wasn't open source, I'm sure many
of the current core developers wouldn't contribute to it. Being open
source is one of the key reasons to contribute to it; it's not an
afterthought.

Regards

Antoine.