[Python-Dev] pysqlite for 2.5?

Anthony Baxter 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 
>   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. :)

> 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 Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

More information about the Python-Dev mailing list