oops! Forgot to select "Reply to all". Sorry for the duplicate, Marc.
--
VC
---------- Forwarded message ----------
From: Vernon Cole <[EMAIL PROTECTED]>
Date: Wed, Sep 24, 2008 at 4:04 PM
Subject: Re: [DB-SIG] First suggestion for db-api 3.0
To: "M.-A. Lemburg" <[EMAIL PROTECTED]>
On Wed, Sep 24, 2008 at 2:36 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> [...] There has been a lot of discussion about these
> parameter styles. The last round concluded that we should strip down
> the number of possible styles to 1 or 2 ('?' and ':1' IIRC).
>
I think it was qmark and named. I agree with dropping the others. -- VC
[...] Also note that the spec does indeed allow the module to return
> namedtuples, but it doesn't require this. The spec deliberately
> uses the term "sequence" instead of tuple or list.
>
> Note that the implementation of namedtuples is not a particularly
> nice one (they use dynamic programming). There's also a different
> implementation available via the C API called structseq (this is used
> e.g. by the time module).
>
> Both create subclasses of the standard Python tuple and are
> sequences, so both are permitted to be used by the DB-API to
> represent rows.
>
So a dbapi 3.0 implementation could be a proper superset of dbapi 2.0. That
would be best. -- VC
> However, using the Python version in an API that potentially
> returns a few thousand rows is not exactly what I'd recommend
> to do, since it will slow down the interface a lot.
>
> Due to the nature of the namedtuples, you will also see many
> different objects as row object (each query will return a
> different object type).
>
> My favorite database (the one I help implement once upon a time) had the
data organized as a virtual array of similar (same class) objects with each
column as a named attribute. (Those are not the terms we used, since object
oriented languages had not been invented then.) That's the model I am used
to thinking in. Our implementation was pretty fast.
Adodbapi is already quite slow, so I doubt if the extra overhead of a named
tuple would actually make that much difference to it. Perhaps I should
download a 2.6 python and muck with it. Those of you working in C would be
emulating the action of a named tuple for performance reasons, I expect,
using your own objects. The implementation details would be unimportant,
provided that the syntax is consistent.
I only know that we are already requiring the user to know two languages:
Python and SQL, in order to use dbapi. Selecting from among the existing ORM
tool kits, and then learning the tool kit, is more of a learning curve than
I could hack. I guess that's why I still don't use an Object Relational
Mapper.
I just want named access to my columns somehow -- so I don't add the
complexity (and inevitable errors) of having to remember the column number
of each field. The access to each column should feel like native Python
--
VC
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
