On Mon, 2008-11-24 at 18:20 -0800, Matt Hancher wrote:
> On Nov 18, 5:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > 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.
>
> [...]
>
> > 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.
>
> Well, I think it's actually not so implausible that option D could
> cause
> someone somewhere a problem. All it would take would be for them
> to have an outdated version of pysqlite2 installed on their system.
> Django would have been happily ignoring it since r3818, and suddenly
> we'd be using it instead. Lord knows how many babies might be killed.
This is what I was hinting at (since I have plenty of modules for python
2.3 and 2.4 sitting around), but think about how it can really happen.
SQLite is a binary module. So you will have had to have intentionally
built a binary module of an earlier version of pysqlite2 for a version
of Python that *already contains* sqlite3. You did this by accident,
apparently, since you didn't know it was an earlier version. Is this
really a use-case we need to cater for?
When you upgrade from Python 2.4 to Python 2.5, your pysqlite2 module
for python2.4 is no longer in the game.
Still, it is a minor inconvenience, so I could still sleep at night if
we went with option A. The need to use the pysqlite2 version apparently
affects Windows users of Python 2.5.1 (maybe 2.5.2 also, I don't know),
since there was some version skew there that Ramiro Morales identified
as a problem and people using spatial support. The latter group can
certainly read about the new setting and use it. It's the former group
I'm a little more concerned about. It includes a lot of beginners who
are not famous for their ability to read documentation or debug problems
as a broad group.
> So, if you're not a fan of option B then I'm inclined to go with the
> conservative option A. Then the question is, what should the
> configuration option look like? Here are two options:
>
> 1: SQLITE_MODULE_NAME = 'pysqlite2'
> 2: DATABASE_OPTIONS = {'module': 'pysqlite2'}
> 3: USE_PYSQLITE2 = True
> 4: # Other
>
> Preferences? My current vote is option 2, because it does not
> introduce a new top-level setting, but it does sort of overload an
> existing one, so I'd understand arguments in favor of option 1.
It's a toss-up between options 1 and 2, isn't it? Normally, I'd prefer
option 1, but it adds a bunch of extra files to support essentially one
import statement.
Since so far only you and I have made real input here, I'd like to hear
what any of the other maintainers (or anybody else who uses this stuff)
thinks. Realistically, any of the options are survivable, so barring any
great arguments one way or the other, we should just pick one and commit
it. I don't see the functionality request as being controversial and I'm
probably putting too much effort into worrying about the fine details.
Cheers,
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
-~----------~----~----~----~------~----~------~--~---
