[Python-Dev] pysqlite for 2.5?
anthony at interlink.com.au
Thu Mar 30 00:47:04 CEST 2006
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.
> 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
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.
> * 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
> * SQLite itself is updated frequently, let alone the wrappers
> * Another external library to track and maybe have emergency updates
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. :)
> 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
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 Baxter <anthony at interlink.com.au>
It's never too late to have a happy childhood.
More information about the Python-Dev