[DB-SIG] Optional DB API Extensions

Andy Dustman andy@dustman.net
26 Oct 2001 17:22:05 -0400


On Fri, 2001-10-26 at 10:57, M.-A. Lemburg wrote:
> Andy Dustman wrote:

> > Generally speaking, I think I prefer methods to read-only attributes.
> > The Db-API interface of MySQLdb is written in Python, and I'd rather not
> > have to deal with __setattr__/__getattr__ hooks if I don't have to. Plus
> > it is arguably better practice for a user interface.
> 
> But didn't you write that you have the .rownumber implemented
> already ?

Well, yeah, but it was cursor._pos, i.e. a private member, not intended
to be exposed to the user, or rather, it was exposed via cursor.tell().
I just renamed it to be rownumber because it was easy... But the main
issue here was not so much cursor.rownumber but cursor.messages vs
cursor.messages(), especially since to clear out messages, you have to
del cursor.messages[:], as I recall... In MySQLdb, you can write to
cursor.rownumber, and it will work, provided it's in range, and you are
using the default Cursor. But using cursor.seek() always works (although
some cursor types are not seekable).

I'm (mostly) ambivalent about scroll() vs. seek().
 
> > > > >    Cursor Attribute .messages
> > > > >    Connection Attribute .messages
> > 
> > Similar, why not cursor.messages(), which returns a list of messages
> > generates, and clears the list, and the same for connection.messages().
> 
> But exposing the plain lists should be very simple on DB API writers
> and its also very useful for DB users that way, since they already know 
> how to manipulate lists (we don't have to invent a new interface 
> for these tasks).

Calling cursor.messages(), which returns a list of messages since the
last call, seems pretty simple to me, and no need to trim the list in a
separate operation.

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
You can have my keys when you pry them from my dead, cold neurons.