Official MySQL module
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.
On Thu, Mar 7, 2013 at 3:41 PM, Thomas Allen <jsbfox@gmail.com> wrote:
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
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). On Thu, Mar 7, 2013 at 12:59 PM, Dustin J. Mitchell <dustin@v.igoro.us>wrote:
-- 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.
On 3/7/2013 4:16 PM, David Mertz wrote:
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.
-- Eric.
On Fri, Mar 8, 2013 at 7:41 AM, Eric V. Smith <eric@trueblade.com> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Mar 7, 2013 at 3:20 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hm. It's true that bsddb was a neverending nightmare. But AFAIR that was due to the bsddb C bindings changing regularly.
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.)
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)
On 08.03.2013 00:20, Nick Coghlan wrote:
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)
::::: 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/
On 3/8/2013 3:06 AM, M.-A. Lemburg wrote:
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.
2013/3/8 Eric V. Smith <eric@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. -- Amaury Forgeot d'Arc
On 3/8/2013 7:39 AM, Amaury Forgeot d'Arc wrote:
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. -- Eric.
On 8 March 2013 08:01, Eric V. Smith <eric@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 -><-
On Fri, Mar 8, 2013 at 6:07 AM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
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.
I do not understand this last phrase. -- --Guido van Rossum (python.org/~guido)
On Mar 8, 2013, at 9:45, Guido van Rossum <guido@python.org> wrote:
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.
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.
On Sat, 09 Mar 2013 16:56:04 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
On 3/8/2013 12:45 PM, Guido van Rossum wrote:
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
On 8 March 2013 14:45, Guido van Rossum <guido@python.org> wrote:
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 -><-
-- --Guido van Rossum (python.org/~guido)
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
On Thu, Mar 7, 2013 at 4:16 PM, David Mertz <mertz@gnosis.cx> wrote:
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).
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/ Dustin
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 <jsbfox@gmail.com> wrote:
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
Gregory P. Smith, 07.03.2013 23:00:
+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
On Thu, Mar 7, 2013 at 3:41 PM, Thomas Allen <jsbfox@gmail.com> wrote:
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
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). On Thu, Mar 7, 2013 at 12:59 PM, Dustin J. Mitchell <dustin@v.igoro.us>wrote:
-- 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.
On 3/7/2013 4:16 PM, David Mertz wrote:
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.
-- Eric.
On Fri, Mar 8, 2013 at 7:41 AM, Eric V. Smith <eric@trueblade.com> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Mar 7, 2013 at 3:20 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hm. It's true that bsddb was a neverending nightmare. But AFAIR that was due to the bsddb C bindings changing regularly.
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.)
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)
On 08.03.2013 00:20, Nick Coghlan wrote:
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)
::::: 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/
On 3/8/2013 3:06 AM, M.-A. Lemburg wrote:
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.
2013/3/8 Eric V. Smith <eric@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. -- Amaury Forgeot d'Arc
On 3/8/2013 7:39 AM, Amaury Forgeot d'Arc wrote:
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. -- Eric.
On 8 March 2013 08:01, Eric V. Smith <eric@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 -><-
On Fri, Mar 8, 2013 at 6:07 AM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
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.
I do not understand this last phrase. -- --Guido van Rossum (python.org/~guido)
On Mar 8, 2013, at 9:45, Guido van Rossum <guido@python.org> wrote:
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.
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.
On Sat, 09 Mar 2013 16:56:04 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
On 3/8/2013 12:45 PM, Guido van Rossum wrote:
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
On 8 March 2013 14:45, Guido van Rossum <guido@python.org> wrote:
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 -><-
-- --Guido van Rossum (python.org/~guido)
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
On Thu, Mar 7, 2013 at 4:16 PM, David Mertz <mertz@gnosis.cx> wrote:
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).
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/ Dustin
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 <jsbfox@gmail.com> wrote:
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
Gregory P. Smith, 07.03.2013 23:00:
+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
participants (17)
-
Amaury Forgeot d'Arc -
Andrew Barnert -
Antoine Pitrou -
David Mertz -
Dustin J. Mitchell -
Eric V. Smith -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Joao S. O. Bueno -
M.-A. Lemburg -
Nick Coghlan -
Stefan Behnel -
Stephen J. Turnbull -
Terry Reedy -
Thomas Allen -
Éric Araujo