[DB-SIG] Some obscurity with paramstyle

Vernon Cole vernondcole at gmail.com
Sun Jul 17 07:52:49 CEST 2011

On Sat, Jul 16, 2011 at 2:27 PM, Michael Bayer <mike_mp at zzzcomputing.com>wrote:

> On Jul 16, 2011, at 3:20 PM, Christoph Zwerschke wrote:
> > At the PyGreSQL mailing list we're currently wondering whether the
> 'format' and 'pyformat' paramstyles allow specifying parameters with types
> other than '%s' - e.g. can I specify my parameter as '%.2f' or '%(name).2f'
> if I want to round floats to 2 digits?
> >
> > PEP 249 has only '%s' in the example, but does not exclude other types,
> > does this mean these are allowed?
> >
> > Also, should we define a new paramstyle for the advanced string
> formatting syntax available since Py 2.6?
> Not all backends that support "format" or "pyformat" would be able to allow
> such behavior - often the client API of the database in use is passed, from
> the DBAPI, the SQL statement with placeholders and the parameters separately
> - no "string formatting" takes place.    A DBAPI that advertises "format" or
> "pyformat" then may or may not be able to handle the extended syntax.
> IMHO I would prefer to see the DBAPI have exactly two paramstyles, named
> and qmark, and have all DBAPIs support both consistently.    The (py)format
> styles continuously introduce the mixing of Python's string formatting
> behavior with the presentation of bound parameters, which are two completely
> different things.
> Another advantage to supporting only those two paramstyles is that it would
make the paramstyle attribute obsolete.
  If the bound parameters form a sequence, qmark is implied, if a mapping,
then named is implied.

Disadvantages would include:
1) some database engines seem to use %s format internally, and efficiency
would be lost in translation.
2) some major applications (e.g. django) assume %s format.

But I am +1 for the idea anyway.
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20110716/7577247c/attachment.html>

More information about the DB-SIG mailing list