On Sat, Jul 16, 2011 at 2:27 PM, Michael Bayer <mike...@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
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
