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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com