[DB-SIG] spec: named parameters: clarification needed

[M.-A. Lemburg]

Harald Meland wrote:
> [M.-A. Lemburg]
> 
> 
>>Anthony Tuininga wrote:
>>
>>>When I wrote cx_Oracle I assumed 2 but I have lately been told that
>>>other drivers have assumed 1 instead, so I am intending to implement
>>>both ways. Perhaps this should be clarified in the API document?
>>
>>That's why I put up the question. Note that the .executeXXX()
>>APIs only define one parameter which is defined as sequence
>>or sequence of sequences, so both options conflict the spec
>>in some way.
> 
> Huh?  From the current spec, and I think this has been in there for
> quite some time:
> 
>     .execute(operation[,parameters])
>           
>         Prepare and execute a database operation (query or command).
>         Parameters may be provided as sequence or mapping and will be
>                                                ^^^^^^^^^^
>         bound to variables in the operation.
> 
> Similar wording is used for .executemany().
> 
> To me, that's pretty clear; am I missing something?

Hmm, you have a point there :-)

Looks as if there's nothing to discuss then, but only to
clarify the meaning of 'named' as paramstyle, namely to
pass in the parameters as dictionary mapping names to values.

>>Given that most drivers which use this param style seem
>>to implement option 2, I guess we should allow keyword
>>parameters to the .executeXXX() methods as well (provided
>>that .paramstyle is set to 'named').
> 
> Umm, if the spec is changes to allow leniency here, it will *further*
> complicate the matter of "my application needs to change database
> driver, and hence I need to transform lots of .execute*() calls for
> purely non-SQL differences".
> 
> Is that really wise?
> 
> If some drivers want to implement args as keyword params, they're
> obviously free to do so, but I'd prefer the spec to stay as it is
> (modulo better wording if necessary, of course).

Agreed. I've always wondered why we need those many different
paramstyles. Ok, I'm biased... ODBC does all the transformations
for me.

-- 
Marc-Andre Lemburg
eGenix.com

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