DB-API format string conventions
Steve Holden
steve at holdenweb.com
Tue Dec 28 08:16:01 EST 2004
Craig Ringer wrote:
> 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?
>
Well, you can certainly put me down as supporting less variability in
allowed paramstyles, to the extent that it would allow much more
application portability.
However, you might not be aware that the reason that variability was
included in the first place is to allow Python module authors to take
advantage of features already available in the various underlying
database platform support code - Oracle, for example, already supports
numbered access (:1), and so on.
So be aware that you are asking the various module authors for
significant amounts of work, which may not be forthcoming under all
circumstances.
Also be aware that there have been various post-2.0 proposals for the DB
API, which you might want to look up on Google and fold in to the
current campaign.
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
More information about the Python-list
mailing list