[Python-Dev] pysqlite for 2.5?
Georg Brandl
g.brandl at gmx.net
Tue Mar 28 12:55:28 CEST 2006
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
More information about the Python-Dev
mailing list