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

Harald Meland Harald.Meland@usit.uio.no
Mon, 17 Feb 2003 21:03:39 +0100


[Anthony Tuininga]

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

You *can* have it both ways, you know:

  def execute(self, statement, params=3D(), **kws):
      if kws and not params:
          self.execute(statement, kws)
      ...

However, then you'd have more than one way to do it, and that's
another language. :-)

(Another (very) minor point: By insisting on using keyword arguments
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 names
for identifiers would restrict you from passing that parameter any
value, short of resorting to giving .execute() a single dict argument.
Yes, I said it was a very minor point.)

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 to
this driver's .execute() method?"

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