On Tue, 2004-12-28 at 18:29, Craig Ringer wrote:
> 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.
MySQLdb, psycopg, and pyPgSQL seem to all support 'pyformat' (python
extended printf) though mysql lists 'format' in paramstyle. I'm not able
to test any other DB interfaces at the moment, but if others support
pyformat then perhaps that's a viable choice to make mandatory in a
revision of the spec? That way any code could check for DB-API 2.1 and
know it could use pyformat style in addition to any other styles the
code permitted. Perhaps more importantly, it could also tell Python
programmers they can rely on pyformat style being available.
IMO it'd also be very nice to support **kw calling style, ie to make:
cursor.execute("SELECT somerow FROM table WHERE otherrow = %(name)s",
{'name': 'fred'})
equivalent to:
cursor.execute("SELECT somerow FROM table WHERE otherrow = %(name)s",
name = 'fred')
frankly, I simply think it's a nicer and more readable calling style
when one is passing a list of parameters directly to .execute() rather
than passing an existing dict. That's just a trivial cosmetic thing,
though, and while it'd be nicer the mixing of the two styles may cost
more in confusion than the latter style gains in readability.
So ... anybody for a DB-API 2.1 with mandatory pyformat support and a
tuple dbmodule.paramstyles for supported styles?
--
Craig Ringer
--
http://mail.python.org/mailman/listinfo/python-list
