This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. What's people's thoughts? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;) OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past. I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable). There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject. Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it. Of course, speaking with Gerhard will be the way to find out more. Georg
Georg Brandl wrote:
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;)
OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past.
That's because I decided for a more rapid release cycle than I used in the past. If bugs are fixed and no features planned to implement in the near future, I made a release.
I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable).
There have been no more bug reports since 2.1, so I'm confident that all the glitches the switch to transparent compiled statements in 2.1 introduced are fixed now.
There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject.
I missed that, can you provide a link please? pysqlite 2 was announced to be incompatible with pysqlite 1. I don't think there were any backwards incompatible API changes in the 2.x line.
Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it.
Of course, speaking with Gerhard will be the way to find out more.
I'll try to throw in a bit more information that will be necessary for this discussion: pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations. I *am* willing to be a maintainer of an SQLite module for Python. I will gladly help writing a PEP for it. But I won't be the champion for the idea, because I'm only +0 on adding external libraries to Python, like elementtree, or ctypes, or pysqlite instead of relying on setuptools/Cheese Shop. I could probably be convinced that a fat Python is still a good idea nowadays, though :-) -- Gerhard
Gerhard Häring wrote:
Georg Brandl wrote:
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;)
OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past.
That's because I decided for a more rapid release cycle than I used in the past. If bugs are fixed and no features planned to implement in the near future, I made a release.
Sounds fair.
I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable).
There have been no more bug reports since 2.1, so I'm confident that all the glitches the switch to transparent compiled statements in 2.1 introduced are fixed now.
There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject.
I missed that, can you provide a link please? pysqlite 2 was announced to be incompatible with pysqlite 1. I don't think there were any backwards incompatible API changes in the 2.x line.
Never mind, you're right. I had another piece of software in my head ;)
Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it.
Of course, speaking with Gerhard will be the way to find out more.
I'll try to throw in a bit more information that will be necessary for this discussion:
pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations.
In what timeframe will those be completed?
I *am* willing to be a maintainer of an SQLite module for Python. I will gladly help writing a PEP for it. But I won't be the champion for the idea, because I'm only +0 on adding external libraries to Python, like elementtree, or ctypes, or pysqlite instead of relying on setuptools/Cheese Shop.
I could probably be convinced that a fat Python is still a good idea nowadays, though :-)
Even though setuptools are a very good concept and implementation, "ships with Python" is still a different kind of statement. Many people think that every external package to maintain is one too much... Georg
Georg Brandl wrote:
Gerhard Häring wrote:
I'll try to throw in a bit more information that will be necessary for this discussion:
pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations.
In what timeframe will those be completed?
I would have waited for a pysqlite 2.2 release until I found a good API for logging for pysqlite (mainly for reporting exceptions in Python callbacks). I will probably defer the logging stuff to pysqlite 2.3 and release pysqlite 2.2 soon with the features currently in SVN. I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release. If this is going to happen, I want it to happen under a different package name than "pysqlite2" and it's probably a good idea to skip "sqlite" too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, "sqlite" would be the natural name if it ends up in Python. Perhaps "sqlitedb" ... Extensive unit tests are available, as is a reference manual in ReST format. -- Gerhard (*) Although if they're really using pysqlite 0.x/1.x then it's unlikely they'll switch to Python 2.5 with their applications.
Gerhard Häring wrote:
I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
If this is going to happen, I want it to happen under a different package name than "pysqlite2" and it's probably a good idea to skip "sqlite" too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, "sqlite" would be the natural name if it ends up in Python. Perhaps "sqlitedb" ...
db.sqlite3 ? (it wraps version 3 of the sqlite engine, after all...) </F>
Fredrik Lundh wrote:
Gerhard Häring wrote:
I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
If this is going to happen, I want it to happen under a different package name than "pysqlite2" and it's probably a good idea to skip "sqlite" too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, "sqlite" would be the natural name if it ends up in Python. Perhaps "sqlitedb" ...
db.sqlite3 ?
That would make sense if inclusion of more database-related modules was planned. Whatever name is chosen: please no "from sqlite3 import dbapi2 as sqlite"! Georg
Georg Brandl <g.brandl@gmx.net> wrote:
Fredrik Lundh wrote:
db.sqlite3 ?
+1
That would make sense if inclusion of more database-related modules was planned.
Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as appropriate, and having a nice new namespace ready for them is a good idea.
Whatever name is chosen: please no "from sqlite3 import dbapi2 as sqlite"!
Amen. db.sqlite3 is the perfect name. Charles -- ----------------------------------------------------------------------- Charles Cazabon <python@discworld.dyndns.org> GPL'ed software available at: http://pyropus.ca/software/ -----------------------------------------------------------------------
On Wednesday 29 March 2006 06:33, Georg Brandl wrote:
Fredrik Lundh wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules was planned.
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules was planned.
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works.
that could be addressed by a plugin facility in db/__init__.py (or by allowing installation tools to add redirection modules to the db directory...)
And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
and extensible_markup_language.document_object_model over xml.dom, I presume ? ;-) </F>
On Wed, Mar 29, 2006, Fredrik Lundh wrote:
Anthony Baxter wrote:
And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
and extensible_markup_language.document_object_model over xml.dom, I presume ? ;-)
While I see your point, from my POV "xml" feels different from "db". Part of it is that XML is *always* referred to that way in texts except for an initial expansion so people know what it stands for, whereas database is only abbreviated in limited circumstances. In addition, three characters is more visible than two. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
+1 on 'database' as the top-level package name. -Barry
Barry Warsaw wrote:
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
+1 on 'database' as the top-level package name.
I think short names are more more consistent with the existing naming in the standard library. +1 on db.sqlite from me. db.sql.sqlite is another possibility, if adding something like Durus or ZODB in the same top-level namespace could be considered for 2.6. -- Gerhard
Hello,
I think short names are more more consistent with the existing naming in the standard library.
+1 on db.sqlite from me.
same for me +1 on db.sqlite
db.sql.sqlite is another possibility, if adding something like Durus or ZODB in the same top-level namespace could be considered for 2.6.
-1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat .... -- bye by Wolfgang
On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote:
-1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat ....
xml.dom.minidom? -- http://www.lexical.org.uk/ | http://covertmusic.com/ | work: adw27@cam.ac.uk "interrupting my train of thought"
On Thursday 30 March 2006 22:25, Andrew Walkingshaw wrote:
On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote:
-1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat ....
xml.dom.minidom?
given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ <wink>
On Thursday 30 March 2006 23:07, Fredrik Lundh wrote:
Anthony Baxter wrote:
xml.dom.minidom?
given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ <wink>
which reminds me -- is that issue still open ? martin? fred?
It looks to me like it's fixed in SVN. http://mail.python.org/pipermail/python-dev/2005-December/058710.html Interestingly, 15 minutes ago I was helping the Ubuntu python packager diagnose exactly the test failure mentioned in this email... Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
It looks to me like it's fixed in SVN.
http://mail.python.org/pipermail/python-dev/2005-December/058710.html
the issue isn't the one in that message though; it's the one in this message: http://mail.python.org/pipermail/python-dev/2005-December/058752.html "I don't agree with the change. You just broke source compatibility between the core package and PyXML." which, I fear, is still unresolved. or ? </F>
Anthony Baxter wrote:
It looks to me like it's fixed in SVN.
http://mail.python.org/pipermail/python-dev/2005-December/058710.html
Interestingly, 15 minutes ago I was helping the Ubuntu python packager diagnose exactly the test failure mentioned in this email...
The problem is that now PyXML is no longer maintainable (not that it has been maintained very well, though): The files that used to be identical in PyXML and Python no longer are identical, so keeping them synchronized adds unreasonable maintenance costs (IMO). Regards, Martin
On 3/30/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The problem is that now PyXML is no longer maintainable (not that it has been maintained very well, though): The files that used to be identical in PyXML and Python no longer are identical, so keeping them synchronized adds unreasonable maintenance costs (IMO).
I don't know what the differences are. Are they large? Can we copy the changes from Python back into PyXML? Or modify both PyXML and Python so they are the same? Could we create a patch that would be applied on importing PyXML to make things easier? n
Neal Norwitz wrote:
I don't know what the differences are. Are they large? Can we copy the changes from Python back into PyXML? Or modify both PyXML and Python so they are the same? Could we create a patch that would be applied on importing PyXML to make things easier?
Primarily, things got renamed from "xml" to "xmlcore" in different places. Porting them to PyXML is besides the point of the renaming, because PyXML then would have to provide an xmlcore package, too. As for actual solution strategies: I haven't yet researched any. Fred indicated he has something in mind, but hasn't been forthcoming over the past few months. Regards, Martin
Fredrik Lundh wrote:
xml.dom.minidom? given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ <wink>
which reminds me -- is that issue still open ? martin? fred?
It still is. I wonder whether I should just revert the change. Regards, Martin
Bill Janssen wrote:
I think short names are more more consistent with the existing naming in the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level package names as aliases for existing shorter top-level package names.
Which existing short names do you have in mind? os? xml? email? Let's not get excited over names here. I say: let the RM or the BDFL, whoever feels responsible to pronounce whether PySQLite actually gets in, decide which name it will have. Georg
On Wed, Mar 29, 2006 at 03:35:48PM +0200, Gerhard H?ring wrote:
Barry Warsaw wrote:
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
+1 on 'database' as the top-level package name.
I think short names are more more consistent with the existing naming in the standard library.
+1 on db.sqlite from me.
db.sql.sqlite is another possibility, if adding something like Durus or ZODB in the same top-level namespace could be considered for 2.6.
two letter names seem short but database is a long word. long words make me thing of java. so i like 'db' ;) +1 on db.sql.sqlite. I was also about to suggest just plain sql.sqlite along the same lines as all of the one people had mentioned so far had really been SQL interfaces rather than general databases. With the bsddb module a common thing for code to do is "from bsddb import db" to have easy to type access to the full bsddb.db.DB object interface. that interface could migrate to live under db.berkeleydb or db.bsddb at some future point in time. -greg
At 07:47 PM 3/29/2006 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other authors to provide 3rd party packages as (for instance) db.mysqldb because of the way package importing works.
See the stdlib module 'pkgutil' for one way around this, that works with existing Python versions. And the 'pkg_resources' module, slated for 2.5a2 inclusion, offers another way, that also works with modules supplied in eggs. So this bit is going to be more of a policy decision (pkgutil vs. pkg_resources) rather than a technical problem per se.
Anthony Baxter <anthony@interlink.com.au> wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
I can't help but be +1. Though I have found various uses for the btree, hash, and recno databases available via bsddb, having a built-in SQL database would be quite convenient; saving people from having to install any one of the dozen+ SQL variants for their platform in order to prototype or even develop a full system using SQL. While I haven't used pysqlite extensively, when I did, I found that it worked quite well for what I was doing. - Josiah
On Tue, 2006-03-28 at 17:59 +1100, Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
SQLite/pysqlite is an awesome combination, and I do think it would make for a more compelling Python distribution. I've used it in several projects, usually with great success. My only hesitation is that in one project, we've had to stick with SQLite 3.2.1 and pysqlite 1.1.6 because we encountered some concurrency problems when trying to upgrade the former to 3.2.8. We couldn't upgrade both to the latest versions due to external project management constraints. But I'm not sure that's enough of a reason to vote against inclusion, so I guess I'm +0. Having Gerhard accept maintainership definitely pushes it from -0 to +0 in my mind. It's got lots of unit tests, so the only thing I'd probably want to see are Python docs for the module. I think Gerhard could still do more frequent releases if he wanted to -- I do that with the email package, and while it's a bit of a PITA, it's doable. Either sqlite or sqlitedb are fine names. -Barry
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say "no", but only because things like ElementTree didn't, either. Does it need a BDFL pronouncement? I'd say yes. Anthony
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say "no",
Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition.
but only because things like ElementTree didn't, either. Does it need a BDFL pronouncement? I'd say yes.
If Guido even cares ;), but if not, RM pronouncement is good enough for me. -Barry
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw <barry@python.org> wrote:
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say "no",
Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition.
FWIW: http://www.rogerbinns.com/apsw.html Jean-Paul
At 04:22 PM 3/28/2006 -0500, Jean-Paul Calderone wrote:
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw <barry@python.org> wrote:
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say "no",
Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition.
That implementation doesn't support the DBAPI, although it sounds as though the differences are mostly shallow and easy to add implementations for. (e.g., implementing the fetch* methods, a description property, etc.). More likely to be an issue is that the author hasn't volunteered to contribute/support it. On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance.
On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote:
On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance.
If there's some general uncertainty about which to add, then it might make better sense to wait and not add either for Python 2.5. -Barry
Barry Warsaw <barry@python.org> wrote:
On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote:
On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance.
If there's some general uncertainty about which to add, then it might make better sense to wait and not add either for Python 2.5.
I'm not sure that there is uncertainty about *which* to add. So far we've seen a handful of +1s for pysqlite, but a link and short discussion about aspw. In my opinion, because pysqlite already has a DBAPI compliant interface to sqlite, and of us who have used it have had positive experiences, I don't see how aspw is even competition, let alone influential enough to push the adoption of an embedded SQL server to Python 2.6 or later. - Josiah
On Wednesday 29 March 2006 08:22, Jean-Paul Calderone wrote:
Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition.
Looks interesting, but not being DB-API compliant is a huge issue for the stdlib. Part of the reason I want to see pysqlite in 2.5 is that it follows the standard DB-API. People can start off using it, then look at switching to a larger database if their application needs grow. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On 3/28/06, Anthony Baxter <anthony@interlink.com.au> wrote:
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say "no", but only because things like ElementTree didn't, either. Does it need a BDFL pronouncement? I'd say yes.
Unless you've recanted on that already, let me point out that I've never seen sqlite, and I've ignored this thread, so I don't know what the disagreement is all about. Perhaps one person in favor and one person against could summarize the argument for me? Otherwise I'll have to go with "no" just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though... -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've never seen sqlite, and I've ignored this thread, so I don't know what the disagreement is all about. Perhaps one person in favor and one person against could summarize the argument for me? Otherwise I'll have to go with "no" just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though...
Let me try to take both sides simultaneously: For: would add an SQL library to the standard distribution, and one that doesn't depend on additional infrastructure on the target machine (such as an existing database server); the author of that library is fine with including it in Python Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later. I'm sure people will add to the list if they think I omitted important points. Regards, Martin
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've never seen sqlite, and I've ignored this thread, so I don't know what the disagreement is all about.
what disagreement ? sqlite is a widely used light-weight SQL library (http://www.sqlite.org) that's an excellent choice for many kind of applications. it has no com- petition in this space. gerald's pysqlite binding is a second-generation implementation of the full DB-API (http://www.python.org/dev/peps/pep-0249/) for sqlite. from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues. </F>
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
I agree with Fredrik here. On the package naming issue: using "em" for "email" would be wrong, just as "db" for "database" would be wrong. I might change my mind if all stdlib packages were under some toplevel package, like "stdlib". Bill
Bill Janssen <janssen@parc.com> wrote:
On the package naming issue: using "em" for "email" would be wrong,
Eh, that should be "import electronic_mail", then. And "import simple_mail_transport_protocol_lib".
just as "db" for "database" would be wrong.
People who are familiar with Extensible Markup Language abbreviate it "xml". People who are familiar with electronic mail abbreviate it "email". And people who are familiar with the concept of a database abbreviate it "db". Why are two right for the stdlib (sorry, "standard library" :), and the other wrong? Charles -- ----------------------------------------------------------------------- Charles Cazabon <python@discworld.dyndns.org> GPL'ed software available at: http://pyropus.ca/software/ -----------------------------------------------------------------------
Charles Cabazon writes:
On the package naming issue: using "em" for "email" would be wrong,
Eh, that should be "import electronic_mail", then. And "import simple_mail_transport_protocol_lib".
just as "db" for "database" would be wrong.
People who are familiar with Extensible Markup Language abbreviate it "xml". People who are familiar with electronic mail abbreviate it "email". And people who are familiar with the concept of a database abbreviate it "db". Why are two right for the stdlib (sorry, "standard library" :), and the other wrong?
Wow, what a world of black-and-white people we've got :-). Here's what I was thinking: "db" and "em" are too short to be useful context-free abbreviations, because there's too much chance of either conflicting with variable names in existing programs, or being confused with some other meaning for those two letters. "email" and "xml", on the other hand, have enough real-world emphasis to be suitable. "stdlib" might or might not be OK ("python_stdlib" might be better, or "pystdlib"); "py" surely isn't. Bill
Bill Janssen wrote:
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
I agree with Fredrik here.
On the package naming issue: using "em" for "email" would be wrong, just as "db" for "database" would be wrong. I might change my mind if all stdlib packages were under some toplevel package, like "stdlib".
I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for "db" or "database". Why can't we just have the pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?! Such a module name is less likely to cause problems. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for "db" or "database".
Why can't we just have the pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?!
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://pythondev@svn.python.org/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration (you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version). It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do: Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change). Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for "db" or "database".
Why can't we just have the pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?!
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
Anything, but please no "db" or "database" top-level module or package :-)
Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://pythondev@svn.python.org/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration
(you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version).
It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do:
Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change).
I take it that this is not going to go into 2.5a1 ?! Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg wrote:
[...] Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ?
- SQLite sources are 1.57 MiB uncompressed, we wouldn't want to add that to the Python sources download size, would we? - I personally would not want to have the job to "bless" a certain version of SQLite for being bugfree enough to be used until the next Python minor release. And we wouldn't want to push a Python minor release just somebody found an obscure data corroption bug in a SQLite release - SQLite might not compile on some less common platforms (AIX, HP/UX, Win64, whatever) that Python compiles fine on. - I believe Python is written in more portable C than SQLite. So it might be certain compilers that fail for compiling SQLite. - At some point you might also want a sqlite commandline shell instead of just the shared library, too. All of these are non-issues if we just compile against an installed SQLite on Unix-like system if it can be found. On Windows, I also prefer to have a dynamically linked SQLite Python module. We can distribute the SQLITE3.DLL with Python, and then people could just download an updated SQLITE.DLL from http://sqlite.org/ and overwrite the existing one of the Python installation, *if* an important bug is fixed in SQLite.
Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ?
This, and that you can prototype without having to install and configure a database server. For many applications, the prototype can be the final version. -- Gerhard
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
Anything, but please no "db" or "database" top-level module or package :-)
How about "sql"? <wink> I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'?
I take it that this is not going to go into 2.5a1 ?!
Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly.
Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ?
For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no "db" or "database" top-level module or package :-)
How about "sql"? <wink>
I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'?
I think sqlite is just fine.
I take it that this is not going to go into 2.5a1 ?!
Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly.
Will it also work with e.g. sqlite 2.8.15 (ie. sqlite < v3) - this is the standard version on SuSE 9.2.
Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ?
For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code.
If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet. What about the Windows build ? Will that contain the necessary DLLs ? Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg wrote:
Will it also work with e.g. sqlite 2.8.15 (ie. sqlite < v3) - this is the standard version on SuSE 9.2.
No, SQLite 3 has a completely different API than SQLite 2.x. If you need a Python module for it, you can use pysqlite 1.0.1.
Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ?
For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code.
If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet.
What about the Windows build ? Will that contain the necessary DLLs ?
I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency - we could make it so that win32 Python core developers (or the Python win32 build process) don't have to build SQLite when building Python -- Gerhard
"Gerhard Häring" <gh@ghaering.de> wrote in message news:442C03D4.1090000@ghaering.de...
I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency
+1 and thanks from a Windows user tjr
Terry Reedy wrote:
"Gerhard Häring" <gh@ghaering.de> wrote in message news:442C03D4.1090000@ghaering.de...
I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency
+1 and thanks from a Windows user
This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)? Regards, Martin
Martin v. Löwis wrote:
Terry Reedy wrote:
"Gerhard Häring" <gh@ghaering.de> wrote in message news:442C03D4.1090000@ghaering.de...
I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency
+1 and thanks from a Windows user
This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)?
AFAIK SQLite does not use stdio or locales. Memory management is normally never done explicitly, but by API calls using opaque pointers to the SQLite structure, for example: - sqlite3_compile will return a SQLite statement. - sqlite3_finalize will clean up the SQLite statement, and return any memory used by it. The only explicit memory management function I know is void sqlite3_free(char *z); which looks ok, too. And pysqlite doesn't use it, anyway. -- Gerhard
M.-A. Lemburg wrote:
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no "db" or "database" top-level module or package :-)
How about "sql"? <wink>
I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'?
I think sqlite is just fine.
sqlite is problematic since the old PySQLite 1.0 (2.x wrapper) had this name. But I'm in favour of a flat name too -- let's use "sqlite3". Georg
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
Anything, but please no "db" or "database" top-level module or package :-)
How about "sql"? <wink>
I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'?
I take it that this is not going to go into 2.5a1 ?!
Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly.
Apart from the tests issue (see python-checkins), doesn't version 1.0 of PySQLite also use the name "_sqlite" for its C module? If so, ours should be renamed too (_sqlite3?) to avoid breaking old apps. Georg
"Anthony Baxter" <anthony@interlink.com.au> wrote in message news:200603310244.33110.anthony@interlink.com.au...
Anything, but please no "db" or "database" top-level module or package :-)
How about "sql"? <wink>
Whereas I am quite happy with a 'db' package, and would like to see other db stuff put under it. tjr
Anthony Baxter wrote:
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that "sqlite" was the name used by the first pysqlite generation: $ python2.3
import sqlite sqlite.version '1.1.6'
I'm not sure how much trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than "none at all". </F>
Fredrik Lundh wrote:
Anthony Baxter wrote:
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that "sqlite" was the name used by the first pysqlite generation:
$ python2.3
import sqlite sqlite.version
'1.1.6'
I'm not sure how much trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than "none at all".
"sqlitedb" is not taken yet. -- Gerhard
M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for "db" or "database".
This would only be an issue for an application that had a private module calle db, since nobody will be trying to publish a top-level module for general use with such a generic name. In that case the application's module would just shadow the db package and the app would continue to work. If the app's author at some point wanted to start using stuff from the new db package, he would just have to rename his module. -- Greg
On 3/29/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
Agreed. As a SQL user, it feels like a no-brainer to me, as well. I'd love to see a DB-API compliant module, and an embedded SQL database, in the core. I don't believe that there's anything comparable to (py)sqlite on that score. And as Anthony pointed out, it provides a nice upgrade path to "bigger" SQL/DB-API solutions. +1 from me. Paul.
On 3/29/06, Paul Moore <p.f.moore@gmail.com> wrote:
On 3/29/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
Agreed. As a SQL user, it feels like a no-brainer to me, as well. I'd love to see a DB-API compliant module, and an embedded SQL database, in the core. I don't believe that there's anything comparable to (py)sqlite on that score.
And as Anthony pointed out, it provides a nice upgrade path to "bigger" SQL/DB-API solutions.
+1 from me.
+1 here, too; just as /f said, the only real issue is time (as in, is it too late to get such a package into 2.5), but with the volunteering I've seen that should be feasible. I just hope we get a BDFL +1 soon so I can add the good news to the 2nd ed of "Python in a Nutshell", which is due to go "printers-wards" about 8-9 days from now (in order to be ready for OSCON -- the times from final text version to paper are NOT brief:-). Alex
On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
Ok - well, I'm willing to work with Gerhard to do this work (for alpha2), Martin's willing to do the Windows build project - so I'm going to say "it's going to be in 2.5". I've really not seen any arguments that convince me otherwise. Martin:
Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later.
I'm happy to do the work (and you've said you're ok to do the windows part). All naming in the stdlib is adhoc by it's nature. We choose a name, and then that's it's name. I'm pretty happy with either 'db.sqlite' or 'database.sqlite', really. I don't think there's an alternative implementation of pysqlite bindings that could be considered for the stdlib. If an alternative to sqlite comes out some time, I don't have a problem with adding it. Phillip:
* Competing Python wrappers exist
There's one - and it's not DB-API compliant. I know a lot of people who use the pysqlite wrapper, I've not come across anything that uses APSW.
* SQLite itself is updated frequently, let alone the wrappers * Another external library to track and maybe have emergency updates of
Only an issue on platforms where we're not using the system-installed version. While sqlite gets new versions, very very few of these are security-related (I can't recall one lately)
* Build integration risks unknown, possible delay of 2.5?
If it's going to cause a delay, it slips until 2.6. Easy. :) Skip:
I haven't been tracking the pysqlite discussion either, but one con you missed is that regardless of pro #1 people will almost certainly apply it to problems for which it is ill-suited, reflectly poorly on both Python and SQLite. Of course, that can and does happen today. Including pysqlite with Python just means it will happen more frequently.
Er - what? Right now, people are far more likely to use bsddb or anydbm for an inappropriate problem space. Adding a _better_ solution makes this better, not worse. I mean, adding ElementTree could also mean people will use XML in more places that are inappropriate, too, but I didn't see that raised as a problem. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On 3/29/06, Anthony Baxter <anthony@interlink.com.au> wrote:
On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
from a user perspective, adding this to the standard library is a no-brainer. the only reason not to add it would be if the release managers don't have time to sort out the build issues.
Ok - well, I'm willing to work with Gerhard to do this work (for alpha2), Martin's willing to do the Windows build project - so I'm going to say "it's going to be in 2.5". I've really not seen any arguments that convince me otherwise.
Sounds like an excellent decision. Having it standard in the Windows build is actually going to be a big plus (though not for me personally :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Anthony> All naming in the stdlib is adhoc by it's nature. We choose a Anthony> name, and then that's it's name. I'm pretty happy with either Anthony> 'db.sqlite' or 'database.sqlite', really. Let's slow down here. If we are really going to start putting together a package infrastructure shouldn't it be done in the context of Brett's great stdlib restructuring PEP? If everything included in the stdlib is under some core package (core, stdlib, py, etc), that suggests that a package containing database wrappers would be named something like stdlib.db or py.database. The existence of a stdlib package certainly isn't a given. Still, let's assume for the moment that's how things fall out and we deliver pysqlite in the stdlib as stdlib.db.sqlite. If I want to install Object Craft's Sybase wrapper the logical place for it seems like stdlib.db.sybase. But that's not right because the Sybase module's not part of the stdlib. Okay, it belongs in site.db.sybase. But now we have two different db packages and the programmer has to care about stdlib vs external. (Maybe that's okay.) I'm sure there are a number of different workable solutions, but shouldn't they be considered before rather arbitrarily deciding that pysqlite belongs in db.sqlite or database.sqlite? If you're not willing to resolve the future naming scheme for 3.x or 2.6 at this point I see no reason start adding any package hierarchy(ies). Just toss it in as the sqlite module (no packaging) and be done with it. Don't start carving up the package namespace without considering the bigger picture. Skip
skip@pobox.com wrote:
If I want to install Object Craft's Sybase wrapper the logical place for it seems like stdlib.db.sybase. But that's not right because the Sybase module's not part of the stdlib. Okay, it belongs in site.db.sybase. But now we have two different db packages and the programmer has to care about stdlib vs external. (Maybe that's okay.)
This seems to be an instance of the general problem of trying to fit a multidimensional classification into a hierarchical structure. Database systems solved this long ago by ditching the hierarchy completely and going relational. Maybe a single dotted hierarchy of package names is too restrictive? Should we be able to import things by specifying attributes instead of a pathname? import db where db.stdlib == True and db.language == "SQL" \ and db.interface == "DBAPI2.0" ?-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == "SQL" \ and db.interface == "DBAPI2.0"
While we're at it, we could spell import "select". :-)
Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access. Constructing bits of SQL out of character strings sucks *extremely* badly. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
At 03:21 PM 3/30/2006 +1200, Greg Ewing wrote:
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == "SQL" \ and db.interface == "DBAPI2.0"
While we're at it, we could spell import "select". :-)
Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access.
Listcomps and generator expressions are effectively equivalent to the nested domain relational calculus -- which is actually more powerful than SQL (which is based more or less on the tuple relational calculus). I've been putting off writing a genexp-to-SQL translator for some time now, but I think somebody else wrote one that actually works; I don't remember if it's SQLAlchemy or one of the other new Python ORM programs. I think it only does the subset of genexps that are easily translated to SQL, but it's certainly a start.
Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access.
Constructing bits of SQL out of character strings sucks *extremely* badly.
Have you looked at SqlObject? (and its associated modules sqlobject.sqlbuilder in particular) http://www.sqlobject.org/module-sqlobject.sqlbuilder.html -greg
On 3/30/06, Gregory P. Smith <greg@electricrain.com> wrote:
Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access.
Constructing bits of SQL out of character strings sucks *extremely* badly.
Have you looked at SqlObject? (and its associated modules sqlobject.sqlbuilder in particular)
SQLAlchemy (www.sqlalchemy.org) is also nice, in particular for more complex setups. I found it scales much better to the insanely complex SQL queries that our home-grown PostgreSQL/Perl setup needs, and it handles transactions the same way as our home-grown ORM too. There's plenty of ways to reliably and sanely avoid typing actual SQL in Python. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
Have you looked at SqlObject? (and its associated modules sqlobject.sqlbuilder in particular)
SQLAlchemy (www.sqlalchemy.org <http://www.sqlalchemy.org>) is also nice, in particular for more complex setups.
There's plenty of ways to reliably and sanely avoid typing actual SQL in Python.
Well, yes, but they all seem to be a bit hackish in one way or another -- e.g. SQLAlchemy's requirement to use &, |, ~ instead of and, or, not. (That's one of the main motivations behind my Overloadable Boolean Operators PEP, by the way.) I'd like to see some way of attacking this problem head-on, rather than endlessly looking for convoluted ways around it. -- Greg
On Thu, Mar 30, 2006 at 12:09:51AM -0800, Gregory P. Smith wrote:
This automatically generated doc concentrates on the interface instead of usage. SQLBuilder is really a capable and very pythonic SQL generator. But it has an issue - it can generate SQL *strings* only for specific databases - because some SQL constructs are DB-dependent, quoting e.g. Some examples are in the __main__ part of sqlbuilder.py: http://svn.colorstudy.com/SQLObject/trunk/sqlobject/sqlbuilder.py Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
We shouldn't include anything without the explicit permission of the author(s); if possible, the authors should grant the PSF permission to change the license (i.e. fill out the contributor agreement). Even better, the authors should be willing to keep the version in Python synchronized with the separate release. Regards, Martin
Martin v. Löwis wrote:
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained.
What's people's thoughts?
We shouldn't include anything without the explicit permission of the author(s);
I'm the only author of the pysqlite 2 codebase, so no problem here.
if possible, the authors should grant the PSF permission to change the license (i.e. fill out the contributor agreement).
That would be no problem either.
Even better, the authors should be willing to keep the version in Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too. -- Gerhard
On 3/28/06, Gerhard Häring <gh@ghaering.de> wrote:
Even better, the authors should be willing to keep the version in Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too.
Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept. However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility. We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle. n
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring <gh@ghaering.de> wrote:
Even better, the authors should be willing to keep the version in Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too.
Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept.
However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit.
My current and future plans for pysqlite are really only additional features, like wrapping the rest of the SQLite API.
Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility.
All my plans for pysqlite are adding more methods to the API, so I see no backwards compatibility problems.
We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle.
I understand your concern for keeping the amount of work for a 2.5 release manageable. So as Anthony Baxter said he'd like to work with me to make this happen, then I think he and I can try to not overload other people with more work. Creating latex docs sounds like I could do it, too. What I'd personally like to offload are these two tasks: - integreting pysqlite into the Python build process - in particular the win32 build process I would have access to Linux and win32 development machines with MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here. -- Gerhard
At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too.
FYI, there's a reST->PythonDoc converter somebody wrote: http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html I'm planning to try it for porting the setuptools docs. I'm sure that editing the result will be required, but it might be a good way to get the mechanical parts of the translation done.
Phillip J. Eby wrote:
At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too.
FYI, there's a reST->PythonDoc converter somebody wrote:
http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
I'm planning to try it for porting the setuptools docs. I'm sure that editing the result will be required, but it might be a good way to get the mechanical parts of the translation done.
I am currently using a somewhat hacked version of Greg Ward's mkpydoc script to convert the ctypes tutorial into libctypes.tex. So far it works great, except that I'm having problems converting a table. I'm in contact with someone from the docutils users list who has helped me with some TeX stuff. The hacked version of mkpydoc is here: http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/docs/manual/mkpydoc.py?rev=1.7&only_with_tag=HEAD&view=markup Thomas
Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too. What I'd personally like to offload are these two tasks:
- integreting pysqlite into the Python build process - in particular the win32 build process
I would have access to Linux and win32 development machines with MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here.
I could create the VC project file if desired. Regards, Martin
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring <gh@ghaering.de> wrote:
Even better, the authors should be willing to keep the version in Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too.
Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept.
However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility.
We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle.
FWIW, I'd volunteer to convert the doc format. Georg
Neal Norwitz wrote:
However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility.
We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle.
This should all depend on volunteers being willing to contribute. If Gerhard wants to do this all on his own, and finds the time - that would be fine with me. Also, if others are willing to help, that could work (e.g. conversion of the documentation could be done by a different contributor). However, the release schedule for 2.5 should not change because of that. Regards, Martin
On Wed, 2006-03-29 at 09:35 +0200, Gerhard Häring wrote:
In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too.
I do things a little differently, at least for the maintenance releases. The email packages in the sandbox svn:external the library from the appropriate Python branch. The rest of the sandbox serves as a repository for all the chrome around releases, e.g. generated docs, setup.py, etc. For email 4.0 I did things a little different, treating it more like a dev branch until it was stable enough to merge back into the trunk (which reminds me, I have to twiddle the sandbox to svn:external it again). That works well for email, but you may want to do something differently. In general though, I think the sandbox is a great place to develop and release standalone packages that are also integrated with Python. So if you wanted to do something similar for pysqlite I'd be totally fine with that. -Barry
participants (27)
-
"Martin v. Löwis" -
Aahz -
Alex Martelli -
Andrew Walkingshaw -
Anthony Baxter -
Barry Warsaw -
Bill Janssen -
Charles Cazabon -
Fred L. Drake, Jr. -
Fredrik Lundh -
Georg Brandl -
Gerhard Häring -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Jean-Paul Calderone -
Josiah Carlson -
M.-A. Lemburg -
Neal Norwitz -
Oleg Broytmann -
Paul Moore -
Phillip J. Eby -
skip＠pobox.com -
Terry Reedy -
Thomas Heller -
Thomas Wouters -
Wolfgang Langner