[DB-SIG] Towards a single parameter style

M.-A. Lemburg mal@lemburg.com
Mon, 17 Feb 2003 09:17:15 +0100


Daniel Dittmar wrote:
> - those wanting to write portable programs find the multiple parameter 
> styles annoying
> - those using only one driver have probably become fond of their current 
> style
> 
> To make it possible to support multiple styles in one driver, I propose 
> the following:
> - connection.cursor () gets an optional keyword parameter 'paramstyle'
> - connection has a writeable attribute which gives the default for this 
> parameter (or perhaps a mapping named 'cursorOptions', in case we want 
> to support more options)

Eek. No. Please don't try to introduce paramstyles per cursor,
that's bound to cause endless problems -- you'll end up having
to deal with 5 different param styles in complex applications
where each programmer starts using its own preferred style. Even
worse, you'd have to switch the applications paramstyle depending
on the cursor you get.

This doesn't even work on the module level, since you might have
the module in use by different plugins of an application expecting
different paramstyles.

The "single parameter style" idea is really one where the programmer
only has a single option and the module takes care of the translation.

Now this would be hard to agree on and it will also break existing
code, so I think we should just make the preferred paramstyle
a suggestion in the DB-API. I'd vote for the simplest of them
all: the 'qmark' style.

If modules want to support multiple paramstyles, they should implement
this in the .executexxx() methods using a new optional parameter
paramstyle. This makes the choice local to where the SQL gets passed
into the interface, so the above concerns should not apply (unless
I'm mistaken).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Feb 17 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford:                                     43 days left
EuroPython 2003, Charleroi, Belgium:                       127 days left