[DB-SIG] spec: named parameters: clarification needed

[Magnus Lycka]

M.-A. Lemburg wrote:
>ODBC was designed to make dealing with multiple database backends
>in a more or less consistent way. To find out how far you can go,
>have a look at the ODBC spec. Believe me, the Python DB API is
>like first day in school compared to a Ph.D. class. mxODBC does
>all the hard work for you here, so there's no need to worry about
>how ODBC works when coding in Python.

Considering the technical state of ODBC and mxODBC today, I think
that it would be great if that would be the standard path for
database access in Python applications today.

Unfortunately, mxODBC is neither the standard for Python database
interfaces, nor an open source product. Ok, it's free in non-commercial
applications, but it's definitely not GPL compatible, nor compatible
with the Python License.

This is not meant to criticize Marc-André in any way, but it *is*
an obstacle for making OBDC a standard in Python. Considering the
awakening interest in the EU for open source software (e.g. the Swedish
agency responsible for public procurements published a very OSS positive
report with some mentioning of python recently) I should perhaps try to
convince my politicians to spend some EU funds on sponsoring an open
source mxODBC! (I guess M-A wouldn't mind a licence change if the price
was right? ;)

A more boring option would be to make a python wrapper for wxODBC,
http://www.wxwindows.org/manuals/2.4.0/wx497.htm

For the "heavy" developers on this list, who are building big products
from scratch, this might not matter, but for the "ordinary" python
users, who mainly use the works of others, the current situation IS a
problem.

There are plenty of freely available python applications today
that talk to SQL databases, usually MySQL or PostgreSQL, sometimes
to two or three different databases. It would be a big win if it
was possible for a python user to download several different database
frontends without having to install, configure and administer MySQL
and PosgreSQL as well if he already has a running MS SQL Server, Oracle
or SapDB installation...

I'm sure such a possibility would also lead to more users of these
applications, which would lead to further development and so on.

I realize that it's completely possible to limit oneself to a certain
database with a generic package like ODBC, by using features that aren't
available in all databases, but today, especially due to the different
parameter styles, it's impossible to write generic code in a standardized
way, since the standard doesn't include a common denominator.

What ever the solution will be: ODBC for all, a standard layer on top of
DB-API, or something completely different, I think I will be happy if
it becomes widely adopted, but it's boring if every project will have
to reinvent the generic approach. This is certainly an area that I feel
should have a standard approach.


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se