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

[M.-A. Lemburg]

Anthony Tuininga wrote:
> The problem is that the spec is not at all clear. Keyword arguments are
> still arguments -- they are turned into a single dictionary which is the
> "right" way in Python to pass arguments by name. 

I'm not sure I can follow you here. The spec talks about a
single optional parameter which happens to be called parameters
(plural) and then states -as Harald corrected me- that this
parameter may either be a sequence or a mapping. That's as clear
as can be.

> Creating a dictionary,
> populating it with arguments and then passing it directly is against
> normal Python syntax (in my opinion, anyway). I realize that until
> Python 2.0 you couldn't pass a dictionary that you had prepared in
> advance (the rare case) as keyword arguments but do we really need to
> consider compatibility with Python 1.5 still?

Hmm, I think you are talking about the apply() syntax
which was added to Python in 2.0... fct(*args, **kws).
That's syntactic sugar which exploits that arguments
are treated internally as tuple and keyword arguments
as dictionary.

However, that's not how you normally call a function
which has keywords or multiple parameters.

> Perhaps what needs to be specified is:
> 
> execute(statement, *parameters) --> sequence (for non-named)
> execute(statement, **parameters) --> mapping (for named)
> 
> And this last one for backwards compatibility if necessary
> 
> execute(statement, parameters) --> sequence or mapping depending on
> module.paramstyle
> 
> Any thoughts on that?

IMHO, there's no need to change the spec, only clarify
it where it is unclear.

> On Sat, 2003-02-15 at 03:52, 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?
>>
>>
>>>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).

-- 
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