<div dir="ltr">oops! Forgot to select "Reply to all". Sorry for the duplicate, Marc.<br>--<br>VC<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Vernon Cole</b> <span dir="ltr"><<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>></span><br>
Date: Wed, Sep 24, 2008 at 4:04 PM<br>Subject: Re: [DB-SIG] First suggestion for db-api 3.0<br>To: "M.-A. Lemburg" <<a href="mailto:mal@egenix.com">mal@egenix.com</a>><br><br><br><div dir="ltr"><br><div class="gmail_quote">
On Wed, Sep 24, 2008 at 2:36 PM, M.-A. Lemburg <span dir="ltr"><<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div> [...] There has been a lot of discussion about these<br></div><div class="Ih2E3d">
parameter styles. The last round concluded that we should strip down<br>
the number of possible styles to 1 or 2 ('?' and ':1' IIRC).<br>
<div></div></div></blockquote><div><br>I think it was qmark and named. I agree with dropping the others. -- VC<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[...] Also note that the spec does indeed allow the module to return<div class="Ih2E3d"><br>
namedtuples, but it doesn't require this. The spec deliberately<br>
uses the term "sequence" instead of tuple or list.<br>
<br>
Note that the implementation of namedtuples is not a particularly<br>
nice one (they use dynamic programming). There's also a different<br>
implementation available via the C API called structseq (this is used<br>
e.g. by the time module).<br>
<br>
Both create subclasses of the standard Python tuple and are<br>
sequences, so both are permitted to be used by the DB-API to<br>
represent rows.<br>
</div></blockquote><div><br>So a dbapi 3.0 implementation could be a proper superset of dbapi 2.0. That would be best. -- VC<br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
However, using the Python version in an API that potentially<br>
returns a few thousand rows is not exactly what I'd recommend<br>
to do, since it will slow down the interface a lot.<br>
<br>
Due to the nature of the namedtuples, you will also see many<br>
different objects as row object (each query will return a<br>
different object type).<br>
<div><div></div><div><br>
</div></div></blockquote></div></div>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. <br>
<br>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. <br>
<br> 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.<br>
<br> 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<br>
--<br>VC<br><br></div>
</div><br></div>