[Python-Dev] pysqlite for 2.5?

[Georg Brandl]

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