[DB-SIG] New update for DB API 1.1

[M.-A. Lemburg]

Andy Dustman wrote:
> 
> On Wed, 24 Mar 1999, M.-A. Lemburg wrote:
> 
> > I've (finally) updated the DB API 1.1 proposal with all the new
> > enhancements and also added a list of open issues:
> 
> Okay, hopefully this will end up being the last round of comments and we
> can wrap this up soon:
> 
> paramstyle: Historically, because of the way MySQL works, the interfaces
> have used the "percent" style. However, it would also be fairly easy to
> also implement the "xpercent" style. From an implementation standpoint,
> this could mean having an alternate executedict method which is like
> execute but expects a dictionary. Or, executeobject which is like
> executedict but expects an object and uses it's __dict__. (This last one,
> unfortunately, avoids use of __getattr__, which is probably a bad thing.)

Hmm, .execute() allows the params argument to be a sequence. Now
in C a Python sequence needs to provide the tp_as_sequence slot,
yet in Python most APIs only rely on a certain interface to be
available, e.g. __len__ and __getitem__. We could loosen the
requirement in the spec to objects having a length and a
__getitem__ slot.

That way, both traditional sequences such as lists, tuples, etc.
would fit the definition, but also mappings such as dictionaries.
If the parameter style is name based, the given names would be
passed to __getitem__, for position based parameters, the
index would serve as argument.

The extract() function in mxTools is an example of how useful
this can be:

>>> extract(sys.modules,('sys','os'))
[<module 'sys'>, <module 'os'>]

>>> extract(sys.modules.keys(),(0,2,1))
['os', 'posix', 'exceptions']

> Possibly execute could test to see if a dictionary is present and use the
> "xpercent" style instead of "percent". Anyway, the real point is: Multiple
> paramstyles are possile for a given database. The two obvious combinations
> are "percent" and "xpercent" and possibly "qmark" or "numeric" and
> "named".

So maybe "paramstyle" should be a sequence of such strings ?!
How would the .execute method then check which style is being
used ?

> Might I also suggest a renaming? Use "format" for the ANSI C type format
> strings and "dictformat" for Python type named format strings.

How about "format" and "pyformat" ?!
 
> Another question is: Does anyone think it would be particularly beneficial
> to allow execute or a varient to work on a dictionary? I think it could
> be, though I'm not sure I would personally use it. I have a module
> (SQLDict) that lets me define Python objects based on a list of column
> names, and these objects can "register" with a SQLDict connection which
> then creates the necessary SQL for inserting, updating, and deletion. So
> the dictionary feature would not be much use to me, but could be useful
> for other applications.

I think widing the definition of "sequence" as proposed above
would make some nifty things possible, e.g. you could pass
an object with __getitem__() method to it which then decides
how to fetch the arguments:
· if the __getitem__ argument is an integer, positional reference
  is needed
· if the argument is a non-integer, named reference is intended

> Lastly, I'm not sure why the buffer object should be the preferred object
> for binary data. I did "discover" them at one point. Basically they seem
> to be mutable strings. Well, really just a C-style buffer. I guess I don't
> see the benefit over using strings. If the normal string/sequence
> operations are available, I suppose it's not a big problem.

The module may need to recognize the binary object type and since
strings are the preferred type for any other string based data,
the buffers fit in nicely as "alternative strings" ;-)

> BTW, I do have permission to release the new MySQL interface. I am waiting
> on word that the lawyers have approved the licensing agreement. Don't
> worry, it's the Python license with the words "Stichting Mathematisch
> Centrum" scratched out and "ComStar Communications Corporation" written in
> with a crayon, and we get rights to your internal organs (by reading this
> message, you have consented to be bound to the license agreement and
> other terms we may think up later).

Cool.

-- 
Marc-Andre Lemburg                               Y2000: 282 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------