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

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.

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

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.

I really wish that that namespace would be "database", not "db". Bill

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, 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

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 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 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

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

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

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. Bill

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

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 Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw 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

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

On Wednesday 29 March 2006 08:22, Jean-Paul Calderone wrote:

...

Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition.

FWIW: http://www.rogerbinns.com/apsw.html

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 It's never too late to have a happy childhood.

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

gerald's pysqlite binding

sorry, gerhard. </F>

Bill Janssen wrote:

On the package naming issue: using "em" for "email" would be wrong, just as "db" for "database" would be wrong.

are you aware of the fact that the module implements the "db-api" ? </F>

Bill Janssen 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 GPL'ed software available at: http://pyropus.ca/software/ -----------------------------------------------------------------------

Charles Cabazon writes:

Whoops! Should be "Cazabon". Bill

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 It's never too late to have a happy childhood.

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

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 ! ::::

"Gerhard Häring" 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

Martin v. Löwis wrote:

Terry Reedy wrote:

...

"Gerhard Häring" 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

I think sqlite is just fine.

I do, too. Bill

"Anthony Baxter" 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

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

On 3/29/06, 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.

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 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 It's never too late to have a happy childhood.

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

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". :-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

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.

On 3/30/06, Gregory P. Smith 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 Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Thu, Mar 30, 2006 at 12:09:51AM -0800, Gregory P. Smith wrote:

http://www.sqlobject.org/module-sqlobject.sqlbuilder.html

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.

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

Neal Norwitz wrote:

On 3/28/06, Gerhard Häring 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

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

Neal Norwitz wrote:

On 3/28/06, Gerhard Häring 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

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