[Python-Dev] pysqlite for 2.5?

[Anthony Baxter]

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.

Martin:
> 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 
part). 

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. 

Phillip:
> * 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 
APSW.

> * 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. :)


Skip:
> 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

-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.