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

[Anthony Tuininga]

On Mon, 2003-02-17 at 15:34, M.-A. Lemburg wrote:
> Anthony Tuininga wrote:
> > On Sun, 2003-02-16 at 03:05, M.-A. Lemburg wrote:
> >>If you like this better, then I'd suggest to add a new method
> >>to your implementation which implements this interface. The spec
> >>is clear about passing only one object in to hold the parameters
> >>for .execute() and as Stuart already explained fits in nicely
> >>with .executemany().
> > 
> > Right. And using keyword arguments passes __ONE__ argument to the
> > underlying function, but in a format that is __MUCH__ easier to read
> > than any of the formats you suggested below. 
> 
> If you think it is so much easier to write, then nobody is stopping
> you from implementing it this way. All I'm saying is that the DB API 2.0
> specifies something different, so your interface is not in line with
> it.

I guess so. I really did think that I was in line with it, though, until
this discussion.... :-(

> There's nothing much to argue here. If you want to stay in line
> I'd suggest to either use a different method name or to tell
> you users about the difference in interpretation.

I plan to implement both in cx_Oracle 3.0 in order to avoid the issue
entirely.

> Most serious apps have an abstraction layer between the application
> code and the database interface anyway, so it is really not
> necessary to get into heated discussions about this.
> 
> You should think of the DB API as a driver API specification not
> an end-user interface.

I certainly have not thought so at all. The fact that you think so
suggests that the DB API spec is not adequate for serious applications
and wouldn't we want it to be? All of the applications and utilities
that I have written have all been written against the "bare" API and I
have not had any issues. Amusingly, all of the drivers that I have used
have included keyword arguments when using named parameters, or the
*args syntax when accepting a sequence of arguments to the execute()
function -- in fact that's how I came to my understanding of the API
because I found the specification misleading in places. So much for the
official API.... :-)

-- 
Anthony Tuininga <anthony@computronix.com>