Include pysqlite2 into Python 2.5?

[Bengt Richter]

On Thu, 21 Oct 2004 18:14:51 +0200, aleaxit at yahoo.com (Alex Martelli) wrote:

>John Fabiani <jfabiani at yolo.com> wrote:
>
>> Great idea and about time.  Python needs some type of default SQL engine.  I
>> have not reviewed what you are doing but may I suggest you take a look at
>> what VFP did with it's built-in data engine.  VFP uses the concept of a
>> cursor along with many built-in commands/functions/statements to work with
>> the data.  
>> 
>> My only question is what happens when SQLLite becomes out of favor i.e. TK
>> is today?
>
>Same as what happens when BSDDB "becomes out of favor", or SAX, etc,
>etc.  Python either keeps supporting it (likely), moves it to a separate
>download rather than bundling it (sensible), or drops it (unlikely but
>not impossible) at some major release.  We're not talking about stuff
>that's particularly "fickle": Tkinter did its job excellently well for
>MANY years, after all, to take your same example.
>
ISTM there could be a useful compromise between inclusion and separate downloads.
I.e., useful addons could be included in the core distribution as proxy stubs
in an add-on package, so that you could interactively type e.g.,

    from addons import sqlite as sql

and if you had not previously done that, the stub would ask you if you'd
like to download and install the thing in question. You could cancel, or
proceed, perhaps with various options. E.g. PIL might let you exclude jpg
support if you didn't want it, and so forth. IIRC&UIAM the BSD ports system
has this kind of functionality -- i.e., instead of full packages, there's
automated download (or off CD) install info pre-packaged.

Options just to download and view release notes or to download docs only
for looking over before installing all might be useful sometimes also.

Like wise, there could be an option to install under addons or site-packages.
And I'm sure people would think of other handy stuff.

There would have to be security checks with md5's or pgp signatures etc.,
but IWT the aproach could be made to work. Official addons could live be
anywhere, even with multiple mirrors, and different components used by
higher level packages could have different urls, but the location urls, sizes, and
hashes would be registered at python.org, so a stub would go there to find
addon info for a particular version of python. This would also guarantee
compatibility (or a notice that no compatible set of required parts is available).

Just a thought.

Regards,
Bengt Richter