[Python-Dev] pysqlite for 2.5?

skip at pobox.com skip at pobox.com
Thu Mar 30 03:32:31 CEST 2006


    Anthony> All naming in the stdlib is adhoc by it's nature. We choose a
    Anthony> name, and then that's it's name. I'm pretty happy with either
    Anthony> 'db.sqlite' or 'database.sqlite', really.

Let's slow down here.  If we are really going to start putting together a
package infrastructure shouldn't it be done in the context of Brett's great
stdlib restructuring PEP?

If everything included in the stdlib is under some core package (core,
stdlib, py, etc), that suggests that a package containing database wrappers
would be named something like stdlib.db or py.database.  The existence of a
stdlib package certainly isn't a given.  Still, let's assume for the moment
that's how things fall out and we deliver pysqlite in the stdlib as
stdlib.db.sqlite.  If I want to install Object Craft's Sybase wrapper the
logical place for it seems like stdlib.db.sybase.  But that's not right
because the Sybase module's not part of the stdlib.  Okay, it belongs in
site.db.sybase.  But now we have two different db packages and the
programmer has to care about stdlib vs external.  (Maybe that's okay.)

I'm sure there are a number of different workable solutions, but shouldn't
they be considered before rather arbitrarily deciding that pysqlite belongs
in db.sqlite or database.sqlite?  If you're not willing to resolve the
future naming scheme for 3.x or 2.6 at this point I see no reason start
adding any package hierarchy(ies).  Just toss it in as the sqlite module (no
packaging) and be done with it.  Don't start carving up the package
namespace without considering the bigger picture.

Skip


More information about the Python-Dev mailing list