<div dir="ltr">oops!&nbsp; Forgot to select &quot;Reply to all&quot;.&nbsp; 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">&lt;<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>&gt;</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: &quot;M.-A. Lemburg&quot; &lt;<a href="mailto:mal@egenix.com">mal@egenix.com</a>&gt;<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">&lt;<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>&gt;</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 (&#39;?&#39; and &#39;:1&#39; 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&#39;t require this. The spec deliberately<br>
uses the term &quot;sequence&quot; 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&#39;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&#39;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&#39;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>&nbsp; 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&#39;s why I still don&#39;t use an Object Relational Mapper.<br>

<br>&nbsp;I just want named access to my columns somehow -- so I don&#39;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>