C
Craig Ringer
Hi all
I've recently been writing some code that for various reasons needs to
support a couple of different PostgreSQL APIs for Python, and have the
potential for MySQL support down the track. I've been running into a
fair bit of trouble with the DB API, in particular the freedom it gives
DB module implementers with regards to Cursor.execute() argument
formatting.
http://python.org/peps/pep-0249.html says that DB modules must have an
attribute paramstyle, to tell the code using the module what string
format convention it requires:
paramstyle
String constant stating the type of parameter marker
formatting expected by the interface. Possible values are
[2]:
There is no discussion, however, of why these _five_ different format
styles are permitted, nor any way the calling code might compensate for
this. Some APIs seem to support more than one style (PyPgSQL comes to
mind here, with both printf+arglist and extended printf+dict support),
but there is no apparent way to discover this. Some modules support
changing paramstyle, others do not, and there's no spec coverage for
this.
This seems to my eyes like a fairly major DB API wart, assuming there's
no nice way to get around it that I'm not aware of. Do I need to write a
format_for_db_API(dbiapi.paramstyle,formatstring) function that converts
an extended printf string to whatever the DB API expects, then use that
every time I call Cursor.execute() ? If so, is there any chance of the
eventual release of a DB API 2.1 that provides a single calling
convention that MUST be supported?
Any enlightenment on this would be much appreciated. I've found the
Python DB API very nice to work with so far (my previous generalised DB
API experience being with the DBI:: package in Perl) but this is really
frustrating me.
If worst comes to worst, I'll just write a simple cursor wrapper that
can translate extended printf calls to whatever the DB API requires, but
it'd be much nicer not to have to implement something as ugly as that to
work around an issue with an otherwise very nice and clear API.
Some digging around on Google Groups suggests that others have run into
this problem, and quite a few have grumbled about it, but there have
been no real answers. So:
Would there be any interest in releasing a DB-API 2.1 with one
parameter style made MANDATORY, and a tuple of other supported styles in
..paramstyles ? I think existing modules implemented in Python could be
retrofitted to take extended printf quite easily, though at a small
performance cost when extended printf was used. Modules in pure C would
be more work, but still probably not a big deal.
I've recently been writing some code that for various reasons needs to
support a couple of different PostgreSQL APIs for Python, and have the
potential for MySQL support down the track. I've been running into a
fair bit of trouble with the DB API, in particular the freedom it gives
DB module implementers with regards to Cursor.execute() argument
formatting.
http://python.org/peps/pep-0249.html says that DB modules must have an
attribute paramstyle, to tell the code using the module what string
format convention it requires:
paramstyle
String constant stating the type of parameter marker
formatting expected by the interface. Possible values are
[2]:
There is no discussion, however, of why these _five_ different format
styles are permitted, nor any way the calling code might compensate for
this. Some APIs seem to support more than one style (PyPgSQL comes to
mind here, with both printf+arglist and extended printf+dict support),
but there is no apparent way to discover this. Some modules support
changing paramstyle, others do not, and there's no spec coverage for
this.
This seems to my eyes like a fairly major DB API wart, assuming there's
no nice way to get around it that I'm not aware of. Do I need to write a
format_for_db_API(dbiapi.paramstyle,formatstring) function that converts
an extended printf string to whatever the DB API expects, then use that
every time I call Cursor.execute() ? If so, is there any chance of the
eventual release of a DB API 2.1 that provides a single calling
convention that MUST be supported?
Any enlightenment on this would be much appreciated. I've found the
Python DB API very nice to work with so far (my previous generalised DB
API experience being with the DBI:: package in Perl) but this is really
frustrating me.
If worst comes to worst, I'll just write a simple cursor wrapper that
can translate extended printf calls to whatever the DB API requires, but
it'd be much nicer not to have to implement something as ugly as that to
work around an issue with an otherwise very nice and clear API.
Some digging around on Google Groups suggests that others have run into
this problem, and quite a few have grumbled about it, but there have
been no real answers. So:
Would there be any interest in releasing a DB-API 2.1 with one
parameter style made MANDATORY, and a tuple of other supported styles in
..paramstyles ? I think existing modules implemented in Python could be
retrofitted to take extended printf quite easily, though at a small
performance cost when extended printf was used. Modules in pure C would
be more work, but still probably not a big deal.