question about including something like sqlite in python

[John Salerno]

I was just thinking, since Python 3.0 is supposed to clean up a lot of
the unnecessary or redundant features of Python and make other things
more streamlined, does it seem to anyone that including SQLite goes
against this goal?

This is just me thinking out loud, mind you, but it seems like including
a database module (especially one that many people won't use in favor
of MySQL or PostgreSQL, etc.) is weighing down the standard library. I
suppose the sqlite module might still be removed in 3.0, but the
inclusion of it at all seems a little strange (and also sort of like an
endorsement for using it).

I can see how it would be helpful to include something like hashlib, for
example, because it streamlines the different hashing modules, and even
ElementTree, which might be seen as the standard way to work with XML.

Anyway, I'd be curious to hear other people's thoughts about this. Maybe
I'm looking at it the wrong way.

 

[Sashmit Bhaduri]

This is just me thinking out loud, mind you, but it seems like including
a database module (especially one that many people won't use in favor
of MySQL or PostgreSQL, etc.) is weighing down the standard library.

Weighing down the standard library? The latest version of sqlite is only
40k SLOC while Python 2.5 incl' the standard library is well over 700k
SLOC.

 

[Ben Finney]

I was just thinking, since Python 3.0 is supposed to clean up a lot
of the unnecessary or redundant features of Python and make other
things more streamlined, does it seem to anyone that including
SQLite goes against this goal?

To my mind, "unnecessary or redundant" is more on the order of
'rfc822', since its functionality is now entirely superseded by
'email'.

This is just me thinking out loud, mind you, but it seems like
including a database module (especially one that many people won't
use in favor of MySQL or PostgreSQL, etc.) is weighing down the
standard library.

Python's philosophy is also one of "batteries included". The module
adds something useful to many people that doesn't currently exist in
Python; but if it's not needed, a module that never gets imported
won't weigh down a program.

If the byte-count size of the standard library on disk is an issue for
someone, Python is probably not the right choice for them.

 

[Dan Sommers]

I can see how it would be helpful to include something like hashlib,
for example, because it streamlines the different hashing modules, and
even ElementTree, which might be seen as the standard way to work with
XML.

None of my python applications works with XML. Including Elementree in
the standard library would do nothing more than weigh it down.

By that logic, about 80% of the standard library is dead weight. ;-)

Anyway, I'd be curious to hear other people's thoughts about
this. Maybe I'm looking at it the wrong way.

Seriously, though, as someone else mentioned, I think it's part of the
nature of the batteries included philosophy. It's difficult to imagine
any one developer (or development shop) using the entire library, so at
least one module must be extraneous. The same might be said of the
language itself: so far, for me, generator expressions and decorators
are also just bogging down the compiler, but that may just be me and the
way I develop the kinds of applications I develop.

Regards,
Dan

 

[John Salerno]

It's difficult to imagine
any one developer (or development shop) using the entire library, so at
least one module must be extraneous.

That's a good point. I guess I am just trying to figure out why I'm a
little surprised sqlite was included, but at the same time I'm excited
to use it and the fact that it will now be standard has caused me to
look into more than otherwise.

 

[skip]

John> I guess I am just trying to figure out why I'm a little surprised
John> sqlite was included, but at the same time I'm excited to use it
John> and the fact that it will now be standard has caused me to look
John> into more than otherwise.

You might find some of the discussion on the python-dev mailing list
instructive:

http://www.google.com/search?hs=Phn...n.org/pipermail/python-dev+sqlite&btnG=Search

This thread looks particularly interesting (and rather long-lived):

http://mail.python.org/pipermail/python-dev/2004-October/049534.html

Skip

 

[Frank Millman]

I was just thinking, since Python 3.0 is supposed to clean up a lot of
the unnecessary or redundant features of Python and make other things
more streamlined, does it seem to anyone that including SQLite goes
against this goal?

This is just me thinking out loud, mind you, but it seems like including
a database module (especially one that many people won't use in favor
of MySQL or PostgreSQL, etc.) is weighing down the standard library. I
suppose the sqlite module might still be removed in 3.0, but the
inclusion of it at all seems a little strange (and also sort of like an
endorsement for using it).

I can see how it would be helpful to include something like hashlib, for
example, because it streamlines the different hashing modules, and even
ElementTree, which might be seen as the standard way to work with XML.

Anyway, I'd be curious to hear other people's thoughts about this. Maybe
I'm looking at it the wrong way.

I was very pleased to learn that pysqlite will be incorporated into
Python 2.5.
Here's why.

I am developing a business/accounting app. As I am targeting the
mid-range, it must be inherently robust and scalable. Therefore I have
restricted the databases supported to two - PostgreSQL on Linux, and MS
Sql Server on Windows. (Yes I know that PostgreSQL works on Windows,
but I figure that if a company has a policy of using MS products, that
will include the database, and if not, a Linux server is a better
option.)

The downside is that there is quite a bit of setting up to do before
you can use it, and that is likely to be a deterrent for someone who
just wants to try it out.

With pysqlite incorporated, I can knock up a demo version that uses it,
and it will work straight out of the box. This is a major benefit. I
have not started looking into it yet, but it is definitely on my to-do
list.

Frank Millman

 

[Magnus Lycka]

I was just thinking, since Python 3.0 is supposed to clean up a lot of
the unnecessary or redundant features of Python and make other things
more streamlined, does it seem to anyone that including SQLite goes
against this goal?

Not to me. I don't see the redundancy. The DB-API spec has been
around for years. I think it's great that one implementation comes
with Python.

This is just me thinking out loud, mind you, but it seems like including
a database module (especially one that many people won't use in favor
of MySQL or PostgreSQL, etc.) is weighing down the standard library. I
suppose the sqlite module might still be removed in 3.0, but the
inclusion of it at all seems a little strange (and also sort of like an
endorsement for using it).

Sure, but primarily it's endorsement for using the the DB-API.

Including SQLite lowers the barrier for getting started in writing
applications in a domain where Python fits well. A domain where
Visual Basic and tools like FoxPro have dominated. Libraries such
as datetime and decimal also goes in the same direction. One could
argue that a simple to use GUI building tool is another requisite
in this domain, but maybe a web tool kit is more appropriaet these
days...

In short I think it helps making Python into a VB-killer, or if
you prefer (yuk!) the new COBOL! ;^)

 

[Aahz]

I was just thinking, since Python 3.0 is supposed to clean up a lot of
the unnecessary or redundant features of Python and make other things
more streamlined, does it seem to anyone that including SQLite goes
against this goal?

Nope. You misunderstand the goals of 3.0 if you think that sqlite goes
against them.