On Mon, 2008-11-17 at 16:19 -0800, Matthew D. Hancher wrote: [...] > Options include: > > A. Leave sqlite3 as the default, and add a configuration setting that > forces use of pysqlite2 if desired. > > B. Always try both sqlite3 and pysqlite2, and use whichever has the > greater version number if both are present. > > C. Same as B, but with an optional configuration option to force one > or the other if desired. > > D. Switch to making pysqlite2 the default, since that's the correct > name for the module if the user has explicitly installed it, and treat > the Python-bundled version as the fallback. > > E. Develop arbitrarily convoluted bits of logic that pay attention to > e.g. what Python version we're running under or the phase of the moon > or something. > > I think I'm personally slightly inclined towards C, but I would be > happy with B or D. I don't really like A because I worry that the > sqlite3 module will become increasingly outdated and this > configuration option will be an extra step and source of confusion for > new users.
I suspect things are a little hairier than you realise, too. There's evidence (by which I mean "people using Windows have reported" -- and despite their choice of OS they seem otherwise reliable) that Windows has a different version of sqlite3 in their Python binaries to what I have, for example, in my Linux (Fedora) installed versions. We should do something, since it's quite reasonable to expect Python 2.5 will be in active use for years to come, so hoping that Python upstream get their act together and/or SQLite development speed slows down are not particularly realistic. I tend to prefer option A (or D), since the number of people who'll really need to use it should be small and, frankly, if you're up to using GIS features, then reading documentation will hopefully be a skill you've already mastered. Beginners won't need to worry about this, since they won't be using features that require this setting to be touched. I dislike options B and C because they will load two modules if you have them both installed. Django's already fairly memory hungry and this only adds to the burden. Option D is not unreasonable, either. I can't think of a way it can backfire, given that pysqlite2 is compiled against a particular Python version and so shouldn't be accidentally importing the 2.4 version with Python 2.5 or something. But I may be missing some outwardly-looking crazy installation option that causes that to happen. Strong -1 on E. It's been suggested previously as a way to work around problems with sqlite3 and Windows and I didn't like it then either (in that particular case, it turned out to be symptomatic of a broader class of bug in SQLite that we still have to fix, so I feel somewhat justified in preferring cleaner code at the time). I guess I prefer D the most, subject to a slight concern if the wrong version could possibly be imported (but I can't imagine how). Then option A. Don't like the others at all. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
