[DB-SIG] Towards a single parameter style

[Anthony Tuininga]

The major problem that I have with this suggestion is that it requires
additional parsing modules to be present and executed, thus adding
significantly to the overhead involved and the amount of code that each
driver needs to include. cx_Oracle is currently written in C and
performs quite well compared to DCOracle2 which contains a Python
wrapper to a bare C wrapper for the OCI (Oracle Call Interface). Writing
a parser in C is a non trivial task. Do we really want to suggest this?

Perhaps I could suggest something else that might allow for the use of a
lower level driver for greater performance for those who care and a
higher level for those who are unconcerned with performance. The higher
level layer could be written in Python and be completely independent of
all the lower level drivers. It could contain all sorts of parsing
modules to convert from the "standard" argument binding mechanism to the
one required by the lower level driver.

Does that sound like something that might work?

On Sun, 2003-02-16 at 16:36, 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)
> 
> Those wanting to switch to the 'standard' parameter style (whatever that 
> may be) will have to change only the part containing the connect, which 
> is driver specific anyway.
> 
> This might work for the current execute() discussion (keyword args vs. 
> dictionary) as well.
> 
> This does not mean that I propose that drivers should be required to 
> support more than one style.
> 
> Daniel Dittmar
-- 
Anthony Tuininga <anthony@computronix.com>