468,101 Members | 1,319 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,101 developers. It's quick & easy.

question about including something like sqlite in python

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.
Sep 11 '06 #1
8 1022
John Salerno wrote:
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.
Sep 11 '06 #2
John Salerno <jo******@NOSPAMgmail.comwrites:
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.

--
\ "My girlfriend has a queen sized bed; I have a court jester |
`\ sized bed. It's red and green and has bells on it, and the ends |
_o__) curl up." -- Steven Wright |
Ben Finney

Sep 11 '06 #3
On Mon, 11 Sep 2006 19:06:45 GMT,
John Salerno <jo******@NOSPAMgmail.comwrote:
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

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
"I wish people would die in alphabetical order." -- My wife, the genealogist
Sep 12 '06 #4
Dan Sommers wrote:
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. :)
Sep 12 '06 #5

JohnI guess I am just trying to figure out why I'm a little surprised
Johnsqlite was included, but at the same time I'm excited to use it
Johnand the fact that it will now be standard has caused me to look
Johninto more than otherwise. :)

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

http://www.google.com/search?hs=Phn&...te&btnG=Search

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

http://mail.python.org/pipermail/pyt...er/049534.html

Skip
Sep 12 '06 #6

John Salerno wrote:
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

Sep 13 '06 #7
John Salerno wrote:
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! ;^)
Sep 14 '06 #8
In article <9t******************@news.tufts.edu>,
John Salerno <jo******@NOSPAMgmail.comwrote:
>
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.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"LL YR VWL R BLNG T S" -- www.nancybuttons.com
Sep 15 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by John Salerno | last post: by
6 posts views Thread by Jorgen Bodde | last post: by
3 posts views Thread by ricardo.turpino | last post: by
1 post views Thread by mikhail.savitsky | last post: by
3 posts views Thread by kyosohma | last post: by
reply views Thread by Guilherme Polo | last post: by
reply views Thread by Joe Goldthwaite | last post: by
20 posts views Thread by timotoole | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.