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

[Anthony Tuininga]

On Mon, 2003-02-17 at 13:03, Harald Meland wrote:
> [Anthony Tuininga]
>=20
> > 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 r=
ead
> > than any of the formats you suggested below.
>=20
> You *can* have it both ways, you know:
>=20
>   def execute(self, statement, params=3D(), **kws):
>       if kws and not params:
>           self.execute(statement, kws)
>       ...
>=20
> However, then you'd have more than one way to do it, and that's
> another language. :-)

True. I'd can the other method [requiring the parameters to be passed=
 in
all at once as a single argument] but the DB API spec seems to requir=
e
it.... :-(

> (Another (very) minor point: By insisting on using keyword argument=
s
> for passing bind param values, you're possibly restricting the
> namespace of bind params; If some database allow you to use
> e.g. ':n=F8ff' as a placeholder, Python's restrictions on valid nam=
es
> for identifiers would restrict you from passing that parameter any
> value, short of resorting to giving .execute() a single dict argume=
nt.
> Yes, I said it was a very minor point.)

Not one that concerns me, really. Why would you want to do something
like that anyway?? :-)

> To my mind, you're trying to force the spec to be overly
> user-friendly, at the cost of making it less interoperable.  One
> consequence of the change you're advocating, is that it'd be harder=
 to
> write a more user-friendly module on top of the DB-API, as it would
> have to figure out "in what way should I pass the bind parameters t=
o
> this driver's .execute() method?"

I like to use cx_Oracle directly and I think user-friendly is good, n=
ot
bad. Sure it makes life a little more difficult for other generic
modules that use it -- that's why I decided to add the additional syn=
tax
support even though I don't like it. I'd prefer, however, that this b=
e
made more clear in the document -- an example would be wonderful. I k=
now
of several people who read it the way I read it -- use keyword argume=
nts
for named parameter binding!

> I would love to see further standardisation of more user-friendly
> Python database stuff, but I really don't think the (current) DB-AP=
I
> is the right place for it; if it is changed towards more leniency, =
I
> think it will *lessen* its interoperability value.

I really think we need a common module for those portability guys whi=
ch
can accept plugins for the different drivers. Yes, someone mentioned
ODBC but it is not particularly friendly for Python. Some things that
are painful to do in C are quite simple to do in Python and it would =
be
nice to have a standard that fits well with Python, not C.

--=20
Anthony Tuininga <anthony@computronix.com>