Roundtrip SQL data especially datetime

[dyork]

When getting data from a database using the dbapi and an SQL query, how do
you in general round trip the data? Especially date-time?

An SQL datetime column translates nicely into a Python datetime (surprise),
which then translates into a string like '2005-08-03 07:32:48'. No problem
with that -- all works quite nicely, until you try to put data back the
other way.

There is no obvious way to parse that string back into a datetime, and
having done so no obvious way to push that back into a SQL datetime column.
Am I missing something?

[I would particularly like to avoid getting trapped by SQL "local settings"
too.]

DavidY

[Gabriel Genellina]

On 15 dic, 07:44, "dyork" <reverse [e-mail]:

When getting data from a database using the dbapi and an SQL query, how do
you in general round trip the data? Especially date-time?

An SQL datetime column translates nicely into a Python datetime (surprise),
which then translates into a string like '2005-08-03 07:32:48'. No problem
with that -- all works quite nicely, until you try to put data back the
other way.

Dont convert to string and keep the datetime object.

--
Gabriel Genellina

[John Machin]

dyork wrote:

When getting data from a database using the dbapi and an SQL query, how do
you in general round trip the data? Especially date-time?

An SQL datetime column translates nicely into a Python datetime (surprise),
which then translates into a string like '2005-08-03 07:32:48'.

It doesn't translate itself. You translated it. As Gabriel has said,
don't do that.

No problem
with that -- all works quite nicely, until you try to put data back the
other way.

There is no obvious way to parse that string back into a datetime,

I suppose it all depends on your definition of obvious :-)

The constructor is datetime.datetime(year, ....., second) so the
following (which works all the way back to Python 2.3) seems not too
obscure to me:

| >>import datetime
| >>s = '2005-08-03 07:32:48'
| >>a = map(int, s.replace('-', ' ').replace(':', ' ').split())
| >>a
| [2005, 8, 3, 7, 32, 48]
| >>dt = datetime.datetime(*a)
| >>dt
| datetime.datetime(2005, 8, 3, 7, 32, 48)

If you have, as you should, Python 2.5, you can use this:

| >>datetime.datetime.strptime(s, '%Y-%m-%d %H:%M:%S')
| datetime.datetime(2005, 8, 3, 7, 32, 48)

and
having done so no obvious way to push that back into a SQL datetime column.

How do you push a str or float object back into an SQL column of
appropriate type? What's the difference? Your DB API should handle this
quite transparently. Try it and see what happens.

HTH,
John

[dyork]

Thanks Gabriel, but when I said "round trip" I really did mean: convert all
the way to string and all the way back again, so your kind advice is not all
that helpful. I need string to get to a non-Python object or a Web page.

DY

"Gabriel Genellina" <ga******@yahoo.com.arwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...

On 15 dic, 07:44, "dyork" <reverse [e-mail]:

>When getting data from a database using the dbapi and an SQL query, how
do
you in general round trip the data? Especially date-time?

An SQL datetime column translates nicely into a Python datetime
(surprise),
which then translates into a string like '2005-08-03 07:32:48'. No
problem
with that -- all works quite nicely, until you try to put data back the
other way.

Dont convert to string and keep the datetime object.

--
Gabriel Genellina

[dyork]

"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...

I suppose it all depends on your definition of obvious :-)

I was looking for a constructor that was the complement of str(). Most/many
languages would provide that. Sometimes it's called parse().

The constructor is datetime.datetime(year, ....., second) so the
following (which works all the way back to Python 2.3) seems not too
obscure to me:

But unobvious in a different way :). Thanks, I'll use that.

If you have, as you should, Python 2.5, you can use this:

I would like to do that, but the tools I need are not released in 2.5 yet.
RSN!

How do you push a str or float object back into an SQL column of
appropriate type? What's the difference? Your DB API should handle this
quite transparently. Try it and see what happens.

Most values tend to work, but only because the SQL string representation
happens to be the same as the Python representation. That may not apply to
some float values, bool, perhaps others. I had hoped the tools would have
solved those problems so I don't have to. In typed languages (Java, C#)
those things tend to just work.

DY

[Carsten Haese]

On Sat, 2006-12-16 at 04:27 +0000, dyork wrote:

"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...

I suppose it all depends on your definition of obvious :-)

I was looking for a constructor that was the complement of str(). Most/many
languages would provide that. Sometimes it's called parse().

We call it time.strptime.

The constructor is datetime.datetime(year, ....., second) so the
following (which works all the way back to Python 2.3) seems not too
obscure to me:

But unobvious in a different way :). Thanks, I'll use that.

If you have, as you should, Python 2.5, you can use this:

I would like to do that, but the tools I need are not released in 2.5 yet.
RSN!

In Python <2.5 you can use this clunky beast:

datetime.datetime(*time.strptime(s, '%Y-%m-%d %H:%M:%S')[:6])

How do you push a str or float object back into an SQL column of
appropriate type? What's the difference? Your DB API should handle this
quite transparently. Try it and see what happens.

Most values tend to work, but only because the SQL string representation
happens to be the same as the Python representation. That may not apply to
some float values, bool, perhaps others. I had hoped the tools would have
solved those problems so I don't have to. In typed languages (Java, C#)
those things tend to just work.

Python is a typed language, too, and "this thing" works just fine,
provided that you are using a reasonable DB-API implementation, and
provided that you're actually binding objects as parameters instead of
just sticking literal strings into your query.

When reading stuff from the database, keep the results in whatever form
they come. Convert to strings for display purposes if you must, but
don't overwrite the object you got from the database if you intend to
save it back into the database. If you need to save a datetime "from
scratch", construct an appropriate object and use it as a parameter to
your insert/update query. If the database module is DB-API 2.0
compliant, it provides a Timestamp factory function for constructing an
appropriate object.

Hope this helps,

Carsten.

[Frank Millman]

dyork wrote:

When getting data from a database using the dbapi and an SQL query, how do
you in general round trip the data? Especially date-time?

This is what I do. I am posting this partly because I hope it helps,
partly because it is a bit clunky and I would appreciate suggestions
for improvements.

I have two constraints.

1. I support PostgreSQL using psycopg, which handles datetime objects
very well, and MS SQL Server using pywin32.odbc, which does not handle
datetime objects at all.

2. PostgreSQL has datatypes for 'timestamp' and for 'date'. I use the
former for things like 'time/date record was created', and the latter
for things like 'invoice date'. However, internally in my app, I only
want to use datetime.datetime objects.

I agree with the principle that dates should only be stored internally
as datetime objects, but I also allow None where the database value is
null. To achieve this I use the following -

import datetime as dt

def dbToDate(date):
if date is None:
return date
if isinstance(date,dt.datetime): # psycopg can return this
type
return date # already in datetime format
if isinstance(date,dt.date): # psycopg can return this type
return dt.datetime.combine(date,dt.time(0)) # convert to
datetime
return dt.datetime.fromtimestamp(int(date)) # win32/odbc
returns type DbiDate

When writing the date back to the database, I cannot pass the datetime
object directly, as pywin32.odbc does not recognise this. I have found
that str(date) - where date is a datetime object - converts it into a
string that is acceptable to both PostgreSQL and MS SQL Server.

HTH

Frank Millman

[John Nagle]

dyork wrote:

"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
I was looking for a constructor that was the complement of str(). Most/many
languages would provide that. Sometimes it's called parse().

>>The constructor is datetime.datetime(year, ....., second) so the
following (which works all the way back to Python 2.3) seems not too
obscure to me:

>

>>If you have, as you should, Python 2.5, you can use this:

Actually, MySQLdb isn't released for Python 2.5 yet, so for
anything with a database, you need an older version of Python.

If you really want to change the conversions for TIMESTAMP, add the
"conv" argument to "connect". Make a copy of "MySQLdb.converters.conversions",
then replace the key "MySQLdb.FIELD_TYPE.TIMESTAMP", which normally has
the value 'mysql_timestamp_converter' with your own converter. You can
then get the interface to emit a "datetime" object.

Routinely converting MySQL DATETIME objects to Python "datetime"
objects isn't really appropriate, because the MySQL objects have a
year range from 1000 to 9999, while Python only has the UNIX range
of 1970 to 2038. Remember, a database may have DATETIME dates which
reflect events in the distant past or future.

None of this will help performance; dates and times are sent over the
connection to a MySQL database as strings.

John Nagle

[Leo Kislov]

John Nagle wrote:

Routinely converting MySQL DATETIME objects to Python "datetime"
objects isn't really appropriate, because the MySQL objects have a
year range from 1000 to 9999, while Python only has the UNIX range
of 1970 to 2038.

You're mistaken. Python datetime module excepts years from 1 up to
9999:

>>datetime.MINYEAR

1

>>datetime.MAXYEAR

9999

-- Leo

[John Machin]

John Nagle wrote:

dyork wrote:

"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...

>If you have, as you should, Python 2.5, you can use this:

Actually, MySQLdb isn't released for Python 2.5 yet

Actually, that's interesting information [why should it take so long?],
but the OP didn't actually say what brand of database he was actually
using :-)

Cheers,
John

[fumanchu]

dyork wrote:

Thanks Gabriel, but when I said "round trip" I really did mean: convert all
the way to string and all the way back again, so your kind advice is not all
that helpful. I need string to get to a non-Python object or a Web page.

Then you need two adaptation layers: one between your app and the DB
(which you already have) and one between your app and the web page or
other user interface.

Here's the web adaptation layer I use:
http://projects.amor.org/misc/browser/alamode.py
Have a look at the coerce_in and coerce_out functions.
Robert Brewer
System Architect
Amor Ministries
fu******@amor.org

[John Nagle]

John Machin wrote:

John Nagle wrote:

>>dyork wrote:

>>>"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.google groups.com...
If you have, as you should, Python 2.5, you can use this:

Actually, MySQLdb isn't released for Python 2.5 yet

Actually, that's interesting information [why should it take so long?],
but the OP didn't actually say what brand of database he was actually
using :-)

True.

Why should it take so long? The Python people don't support the
MySQL interface, and the MySQL people don't support the Python interface.
There's one guy on Sourceforge doing the MySQLdb glue code. And he's busy.

This is unusual for database bindings. The standard Perl distribution
supports MySQL and several other databases, so you can use MySQL
out of the box, and it's tested for new releases. The standard MySQL
distribution supports PHP, Java, etc., so that's standard and gets
tested.

With Python/MySQL, though, neither side takes responsibility
for making that binding work.

One side effect of this being third party code is that hosting
services may not have it available, even when they have both Python
and MySQL up. This is never a problem with Perl or PHP, so that's
a negative for Python. I'm currently trying to get "EZpublishing",
usually a good hosting service, to fix this on their systems.

There are also some recent problems between versions of
Apache, mod_python, MySQLdb, Python, and MySQL, some of which can
crash a web server. (Ref:
http://packages.debian.org/changelog...p2-4/changelog)
Not sure if this has been resolved yet.

John Nagle

[Marc 'BlackJack' Rintsch]

In <B0******************@newssvr14.news.prodigy.net >, John Nagle wrote:

John Machin wrote:

>John Nagle wrote:

>>>dyork wrote:
"John Machin" <sj******@lexicon.netwrote in message
news:11**********************@f1g2000cwa.googl egroups.com...
>If you have, as you should, Python 2.5, you can use this:

Actually, MySQLdb isn't released for Python 2.5 yet

Actually, that's interesting information [why should it take so long?],
but the OP didn't actually say what brand of database he was actually
using :-)

True.

Why should it take so long? The Python people don't support the
MySQL interface, and the MySQL people don't support the Python interface.
There's one guy on Sourceforge doing the MySQLdb glue code. And he's busy.

AFAIK there's no MySQLdb module for Python 2.5 on *Windows* yet, because
the author of the module doesn't use Windows anymore and he don't want to
maintain a binary he can't test.

Ciao,
Marc 'BlackJack' Rintsch

[John Nagle]

Marc 'BlackJack' Rintsch wrote:

In <B0******************@newssvr14.news.prodigy.net >, John Nagle wrote:

>>John Machin wrote:

>>>John Nagle wrote:

dyork wrote:

>"John Machin" <sj******@lexicon.netwrote in message
>news:11**********************@f1g2000cwa.goog legroups.com...
>
>
>
>>If you have, as you should, Python 2.5, you can use this:

Actually, MySQLdb isn't released for Python 2.5 yet
Actually, that's interesting information [why should it take so long?],
but the OP didn't actually say what brand of database he was actually
using :-)

True.

Why should it take so long? The Python people don't support the
MySQL interface, and the MySQL people don't support the Python interface.
There's one guy on Sourceforge doing the MySQLdb glue code. And he's busy.

AFAIK there's no MySQLdb module for Python 2.5 on *Windows* yet, because
the author of the module doesn't use Windows anymore and he don't want to
maintain a binary he can't test.

The SourceForge page

http://sourceforge.net/project/showf...group_id=22307

says

"MySQL versions 3.23-5.0; and Python versions 2.3-2.4 are supported."

Last release was April, 2006. There's no binary for Python 2.5 yet.

See the help discussions for the project. Apparently you can build
it for Python 2.5 from the SVN repository and it can be made to work,
but just building it may not work on your platform. Some edits
may be required. Problems have been reported with the Windows version
and the 64-bit Linux version.

These are all normal development issues. But they're not fully resolved
yet. So users should hold off from using Python 2.5 in production
database applications.

John Nagle

[Carsten Haese]

On Sat, 2006-12-16 at 20:48 +0000, John Nagle wrote:

The SourceForge page

http://sourceforge.net/project/showf...group_id=22307

says

"MySQL versions 3.23-5.0; and Python versions 2.3-2.4 are supported."

Last release was April, 2006. There's no binary for Python 2.5 yet.
[...]
So users should hold off from using Python 2.5 in production
database applications.

This may come as a shock to you, but MySQL is not the only database
engine on the planet. Your recommendation may apply to MySQL, but it is
not true for all databases in general. I can name at least two examples
(Informix and Oracle) of database engines that are supported under
Python 2.5, and if I were less lazy I could probably find more.

-Carsten

[John Machin]

Carsten Haese wrote:

On Sat, 2006-12-16 at 20:48 +0000, John Nagle wrote:

The SourceForge page

http://sourceforge.net/project/showf...group_id=22307

says

"MySQL versions 3.23-5.0; and Python versions 2.3-2.4 are supported."

Last release was April, 2006. There's no binary for Python 2.5 yet.
[...]
So users should hold off from using Python 2.5 in production
database applications.

This may come as a shock to you, but MySQL is not the only database
engine on the planet. Your recommendation may apply to MySQL, but it is
not true for all databases in general. I can name at least two examples
(Informix and Oracle) of database engines that are supported under
Python 2.5, and if I were less lazy I could probably find more.

Not sure if sqlite qualifies as an "engine", but it works just fine
with Python 2.5. Heck, it's even supplied in the standard python.org
distribution, Windows DLL and all and all ...

[Diez B. Roggisch]

>

Most values tend to work, but only because the SQL string representation
happens to be the same as the Python representation. That may not apply to
some float values, bool, perhaps others. I had hoped the tools would have
solved those problems so I don't have to. In typed languages (Java, C#)
those things tend to just work.

Not true. There might be frameworks that aid this process - as there are
for python (e.g. TurboGears validators), but especially when it comes to
dates, even the larger ones like Struts for Java pretty much suck.

Diez

[Fredrik Lundh]

dyork wrote:

Most values tend to work, but only because the SQL string representation
happens to be the same as the Python representation. That may not apply to
some float values, bool, perhaps others. I had hoped the tools would have
solved those problems so I don't have to. In typed languages (Java, C#)
those things tend to just work.

if you think that Python isn't typed, you've completely missed how
things work. your problem is that you're removing every trace of the
type information by casting everything to strings, not that Python
itself (nor the database adapters) cannot handle typed data.

</F>

[Hertha Steck]

Am Sat, 16 Dec 2006 16:31:18 -0500 schrieb Carsten Haese:

>
This may come as a shock to you, but MySQL is not the only database
engine on the planet. Your recommendation may apply to MySQL, but it is
not true for all databases in general. I can name at least two examples
(Informix and Oracle) of database engines that are supported under
Python 2.5, and if I were less lazy I could probably find more.

Interbase / Firebird:

http://sourceforge.net/project/showf...?group_id=9913

All you need, Windows binaries, .src.tar.gz for Python 2.3 - 2.5, Firebird
1.0 - 2.0.

[dyork]

"fumanchu" <fu******@amor.orgwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...

Here's the web adaptation layer I use:
http://projects.amor.org/misc/browser/alamode.py
Have a look at the coerce_in and coerce_out functions.

Thanks! Plenty of useful ideas there.

My web framework already does all the HTML stuff, so I don't need that.
Also, I note that alamode has hard coded dates in MDY order, which is
surprising given the Unicode support, and a real problem.

DY

[dyork]

"Carsten Haese" <ca*****@uniqsys.comwrote in message
news:ma***************************************@pyt hon.org...

Python is a typed language, too, and "this thing" works just fine,
provided that you are using a reasonable DB-API implementation, and
provided that you're actually binding objects as parameters instead of
just sticking literal strings into your query.

I'm currently using MySQLdb, but I'm looking for solutions that work
universally.

Binding objects is no different from literal strings. Since there is no
portable underlying type for an SQL date, the interface will AFAIK always
finish up using strings. At some point the SQL parser has to convert a
literal string, either embedded in the query or bound as a parameter, into
the equivalent date. I really hope the dbapi will know how to choose the
right string format so I don't have to, but so far that's not at all
certain.

When reading stuff from the database, keep the results in whatever form
they come. Convert to strings for display purposes if you must, but
don't overwrite the object you got from the database if you intend to
save it back into the database.

That's not feasible. For Web stuff, the object from the database got thrown
away after the page was rendered. We're dealing with a whole new request,
with little or no previous state, and all the dates coming in with the
request are strings, using formatting that depends on what the user wanted
to see. I need to package that into a form ready for either an INSERT or
UPDATE query. The user might have typed in dd-mmm-yy order, but the database
interface might use mm/dd/yyyy. It needs two conversion layers, and I would
rather use someone else's than write my own. Lazy, I guess.

DY

[dyork]

"Carsten Haese" <ca*****@uniqsys.comwrote in message
news:ma***************************************@pyt hon.org...

This may come as a shock to you, but MySQL is not the only database
engine on the planet. Your recommendation may apply to MySQL, but it is
not true for all databases in general. I can name at least two examples
(Informix and Oracle) of database engines that are supported under
Python 2.5, and if I were less lazy I could probably find more.

Of course, no question about it.

However, the database is currently in MySQL and it's convenient to keep
working with it, given the other apps and other tools I'm using.

This would be the first time I've been told: don't use that database, the
language doesn't like it.

DY

[dyork]

"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote in message
news:ma***************************************@pyt hon.org...

If you actually look at what the various DB-API adapters produce
when sending to the database engine, floats, bools, etc. are all sent as
string representations; about the only source for problems would be
involved in the number of significant digits transferred for a float
(you might feed 15 digits in, and only get 7 or 10 back)

Having written adapters myself, I would not be confident that is true. It's
convenient to use native formats for floats and ints, and strings for
everything else. Regardless, you get trouble with (a) nulls (b) dates/times
(c) decimal/currency (d) precision mismatches (e) collation mismatches (f)
blobs (g) Unicode (h) special values like NaN. It takes great attention to
detail to be sure it all works, and I really don't want to write it (again).

I'd just like to choose some product X and "It Just Works"!

DY

[dyork]

"John Nagle" <na***@animats.comwrote in message
news:i5*****************@newssvr12.news.prodigy.ne t...

Actually, MySQLdb isn't released for Python 2.5 yet, so for
anything with a database, you need an older version of Python.

It's not really a problem so far.

If you really want to change the conversions for TIMESTAMP, add the
"conv" argument to "connect". Make a copy of
"MySQLdb.converters.conversions",
then replace the key "MySQLdb.FIELD_TYPE.TIMESTAMP", which normally has
the value 'mysql_timestamp_converter' with your own converter. You can
then get the interface to emit a "datetime" object.

Thanks! Very helpful. Actually, it's DATETIME I want and not TIMESTAMP, but
you certainly pointed me in the right direction.

Turns out the author of MySQLdb knows his onions, and virtually all of what
I need is in there. Seems it's critical to send in the right Python type to
trigger the right conversion routine to get the right result, and some of
the choices are not completely obvious. Still, the concept is good.

None of this will help performance; dates and times are sent over the
connection to a MySQL database as strings.

Whenever you touch SQL (a) you talk strings and (b) performance belongs on a
different planet. I can live with that.

DY

[dyork]

"Fredrik Lundh" <fr*****@pythonware.comwrote in message
news:ma***************************************@pyt hon.org...

if you think that Python isn't typed, you've completely missed how things
work. your problem is that you're removing every trace of the type
information by casting everything to strings, not that Python itself (nor
the database adapters) cannot handle typed data.

Fortunately, I'm not offended. I know perfectly well that Python variables
are NOT typed, that Python relies on a dynamically typed model and most
other languages support static typing.I assume you know that too.

The advantage of static typing in this context is that the variable still
holds the type even if the value happens to be null. Any value that has been
exposed to user input comes back as a string and has to be validated and
converted to the correct data type. Static typing provides a convenient
place to generically find out what that type is, to drive a
validator/convertor. There are many ways to do the equivalent in Python, and
I'm interested in any suggestions that save me some work.

DY

[Diez B. Roggisch]

>

The advantage of static typing in this context is that the variable still
holds the type even if the value happens to be null. Any value that has been
exposed to user input comes back as a string and has to be validated and
converted to the correct data type. Static typing provides a convenient
place to generically find out what that type is, to drive a
validator/convertor. There are many ways to do the equivalent in Python, and
I'm interested in any suggestions that save me some work.

While this information in statically typed languages _can_ be used (but
not always is, in a web context), it also is available in the database
schema, which ultimately decides what it groks and what not.

But this is - especially in web-development - only half the truth.
Because even such a simple thing as reading a float value from the user
gets complicated in the presence of different locales. It buys you
nothing then to have static type declarations available.

A decent framework for webdevelopment, as e.g. TurboGears, allows you to
declare form field validation and coercion rules, thus on a higher
application level (your code), you only deal with the correctly typed
values.

Diez

[fumanchu]

dyork wrote:

"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote in message
news:ma***************************************@pyt hon.org...

If you actually look at what the various DB-API adapters produce
when sending to the database engine, floats, bools, etc. are all sent as
string representations; about the only source for problems would be
involved in the number of significant digits transferred for a float
(you might feed 15 digits in, and only get 7 or 10 back)

Having written adapters myself, I would not be confident that is true. It's
convenient to use native formats for floats and ints, and strings for
everything else. Regardless, you get trouble with (a) nulls (b) dates/times
(c) decimal/currency (d) precision mismatches (e) collation mismatches (f)
blobs (g) Unicode (h) special values like NaN. It takes great attention to
detail to be sure it all works, and I really don't want to write it (again).

I'd just like to choose some product X and "It Just Works"!

Ah. Then feel free to have a look at Dejavu, wherein I've worked all
that out for you (okay, not NaN, but that wouldn't be hard).

A quick look over
http://projects.amor.org/dejavu/brow.../storemysql.py
shows proper string escaping, correct handling of 1/0 for True and
False, encoding, max precision, CURDATE, automatic scaling to BLOB
columns for bytes 255, and BLOB index limitations. All of the Null,
date/time, decimal, unicode, and other type adaptation support is in
the generic
http://projects.amor.org/dejavu/brow...ge/geniusql.py

The same goes for Postgres, MS Access, SQLite, and SQL Server. Firebird
and sqlite3 are in the works.

Simple docs at http://projects.amor.org/docs/dejavu/
Robert Brewer
System Architect
Amor Ministries
fu******@amor.org

[John Machin]

dyork wrote:

"Carsten Haese" <ca*****@uniqsys.comwrote in message
news:ma***************************************@pyt hon.org...

This may come as a shock to you, but MySQL is not the only database
engine on the planet. Your recommendation may apply to MySQL, but it is
not true for all databases in general. I can name at least two examples
(Informix and Oracle) of database engines that are supported under
Python 2.5, and if I were less lazy I could probably find more.

Of course, no question about it.

However, the database is currently in MySQL and it's convenient to keep
working with it, given the other apps and other tools I'm using.

This would be the first time I've been told: don't use that database, the
language doesn't like it.

Simple fact: mySQLdb is not yet available for Python 2.5.
Nobody has said (or even hinted) that "the language doesn't like it."

[GHUM]

One side effect of this being third party code is that hosting

services may not have it available, even when they have both Python
and MySQL up. This is never a problem with Perl or PHP, so that's
a negative for Python.

I for one think it is a good thing to not have MySQL adapters
integrated into Python core. Neither the philopsophie, nor the licence
of the two products fit together.

But maybe that's because I am a PostgreSQL zealot - and PostgreSQL and
Python is really a match made in heaven.

Harald

[John Nagle]

GHUM wrote:

> One side effect of this being third party code is that hosting
services may not have it available, even when they have both Python
and MySQL up. This is never a problem with Perl or PHP, so that's
a negative for Python.

I for one think it is a good thing to not have MySQL adapters
integrated into Python core. Neither the philopsophie, nor the licence
of the two products fit together.

It's a wire protocol. At one end of a socket, there's MySQL, and
at the other end, there's a client. Neither side needs code from
the other. The protocol is published. So there's no license issue.

John Nagle