[Python-ideas] sqlite3

[Brett Cannon]

On Thu, May 16, 2013 at 9:41 AM, Henshaw, Andy
<Andy.Henshaw at gtri.gatech.edu> wrote:
> From: M.-A. Lemburg [mailto:mal at egenix.com]
>>On 16.05.2013 14:18, Henshaw, Andy wrote:
>>> From: Stephen J. Turnbull [mailto:stephen at xemacs.org]
>>> Henshaw, Andy writes:
> ...
>>>
>>> But, Python only ships one sqlite module.  If there were two versions
>>> of the module and the developer needed to choose, then it would make
>>> sense.  Why isn't there a tkinter8 to indicate with which version of
>>> tcl/tk the module is designed to operate?  It seems like we're just
>>> propagating an awkward, vestigial, implementation detail for no good reason.
>
>> sqlite3 requires version 3.x of sqlite. It is not compatible with version 2.x
>> of sqlite due to API changes in sqlite, hence the version number in the name.
>
>> Here's the thread discussing the addition:
>> http://mail.python.org/pipermail/python-dev/2006-March/062905.html
>
> Interesting.  It appears that they took the first name suggested, although
> there were multiple suggestions of just "sqlite" variants (e.g., db.sqlite or
> database.sqlite).
>
> Really, this is not important enough to continue arguing about, so I intend
> that this will be my last post on the subject.  However, I don't think that my
> point has been addressed.  Python only ships one version of the module, so
> there is no important reason to append a version number to the module name.
> It's a convention not done for other modules that wrap libraries, excepting maybe
> bzip2(bz2) and MD5, but those are the formal names (according to Wikipedia), and
> it should be deprecated for sqlite.

Just so people have a glimpse of how a decision like this is made, I'm
going to quickly reply and then consider the topic closed.

If we go with the assumption that the name "sqlite3" is sub-optimal
compared to "sqlite", taking the effort to deprecate the old name and
switch to a new one is not at all worth it at this point. If we
deprecated the name then every Python program *in the world* that used
that module would need updating at some point (or we at least need to
make that assumption). That is a massive undertaking when looked at in
an aggregate fashion just to make a name fit more a project name than
a project version/format name.

If there had been found some confusion over the name then during the
Python 2/3 switch we could have changed it so that 2to3 could have
handle the name change like the urllib changes, etc. But since there
is no reported confusion to any level high enough to even warrant that
headache for code that tries to be source-compatible between Python 2
and 3 the module name won't change probably unless sqlite 4 came out,
was not backwards-compatible, and we decided to support it in the
stdlib.