<div dir="ltr">One of those attributes needs to move anyway.  In order to make the paramstyle switchable, it needs to be an attribute of the connection, so that a client who is supporting multiple connections to multiple engines (like, for example the database connection server I am writing right now) does not have trouble with the different streams stepping on each other.  Most of the cruft is already hanging on the connection, and taking it out would break too much old code -- so we might as well put to remaining cruft in. <br>

<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 4:24 PM, Dan Lenski <span dir="ltr"><<a href="mailto:dlenski@gmail.com" target="_blank">dlenski@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Michael Bayer <mike_mp <at> <a href="http://zzzcomputing.com" target="_blank">zzzcomputing.com</a>> writes:<br>


</div><div class="im">> On Apr 22, 2013, at 12:44 PM, Dan Lenski <dlenski <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
><br>
> > I get your point about not crufting up DBAPI with a bunch of high-level<br>
> > features that will need to be reimplemented for each module...<br>
> ><br>
> > But this seems to me precisely the kind of feature that *should* exist at<br>
> > this level, because it makes it easier for higher-level interfaces to<br>
> > manipulate the underlying database objects in a generic way without<br>
carrying<br>
> > around extra module-dependent state on their own.<br>
><br>
> well I will say that there is precedent for this specific request - the<br>
cursor.connection attribute is part<br>
> of the spec, and is pretty harmless, and the spec also includes the option<br>
for the DBAPI exception classes<br>
> to be attached onto the Connection, which you can see here:<br>
> <a href="http://www.python.org/dev/peps/pep-0249/#optional-db-api-extensions" target="_blank">http://www.python.org/dev/peps/pep-0249/#optional-db-api-extensions</a>.  If<br>
we're sticking the<br>
> module-level exception classes directly onto the connection (which I find<br>
kind of distasteful, but<br>
> there it is), might as well put *all* module-level constants onto it.<br>
<br>
</div>Ah yes, that is quite a similar case.<br>
<br>
Since DBAPI specifies all these constants at the module-level, why not just<br>
include connection.module and cursor.module attributes to make them available?<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
DB-SIG maillist  -  <a href="mailto:DB-SIG@python.org">DB-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/db-sig" target="_blank">http://mail.python.org/mailman/listinfo/db-sig</a><br>
</div></div></blockquote></div><br></div>