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

[Anthony Tuininga]

On Mon, 2003-02-17 at 19:30, Kevin Jacobs wrote:
> On Mon, 17 Feb 2003, Anthony Tuininga wrote:
> > > 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?
> 
> DB-API for all of its short-comings is very well suited for serious
> applications.  Unless, of course, syntactic sugar based on your particular
> tastes have suddenly become a requirement.

Of course not. But code that is easier to read is also much easier to
maintain. I think we can agree on that, right?

> Seriously...  get a grip.  There are _much_ more important things to argue
> about than silly keyword arguments for a function that _everyone_ manages to

Give it a rest. I did not suggest that this was an extremely serious
issue that absolutely needs to be addressed or the DB API is unsuitable
for "serious" applications. Reread my post, thanks. I noticed that you
cut out the part of my post that said that I too believe that the DB API
is suitable for "serious" applications. What I was stating (if you read
carefully) is that a statement of "think of the DB API as a driver API
specification and not an end user interface" is a means of stating that
you should not use the bare API but __always__ write a layer on top. If
everyone does that, what is the purpose of the API then except to make
porting a little simpler than not (rewrite your "sugar" layer). I always
thought it was intended to be __USED__ not wrapped!

> figure out.  If you don't like it, then fix it for your own applications. 
> This is Python after all -- you're not stuck with a one-size-fits-all
> solution.  

Of course. I have done so in many cases. That said, I prefer to use code
that others have written or to write code that others can use. And in
order to do that, it is helpful to get the opinions of others, rather
than simply go my own way all the time, right?

> > -- 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.... :-)
> 
> Then work to clarify it, not arbitrarily permute parts that are generally
> well understood.  If it matters that much, then put in the effort to help
> define a community supported DB-API 3.0 that includes features that scratch

That's what I thought I was doing. Perhaps you can give some advice from
your vast store of it?

> your itch.  However, you will want to take a serious look at what people are
> doing with DB-API before you are judge yourself qualified to make such
> pronouncements and expect to be taken seriously.

Reread my post. I did not say that using a single parameter for execute
made the DB API unsuitable for serious applications. Read it again. I
have looked at other implementations of the DB API -- and found plenty
to confuse the issue in spite of how "obvious" you (and a couple of
others) seem to find it.

> Just one author of "serious" applications built upon DB-API,
> -Kevin

Another author of "serious" applications built upon DB-API.

-- 
Anthony Tuininga <anthony@computronix.com>