<div dir="ltr"><div><div><div>Yes, I _like_ that idea.  I'm not so sure about "database" being the correct name for the attribute, but the idea itself is the correct "obvious way to do it", I think.<br>

</div>  I have just finished tearing all of the cruft stuff (exceptions, translations, etc) out of adodbapi into a separate module so that it would be re-useable. It also makes the package easier to understand. Now my test code contains a lot of...<br>

</div>import adodbapi<br></div>import adodbapi.apibase as api<br>...<br>try:<br>
    cursor = connection.cursor()<br>
    cursor.execute(...)<br>
except api.DataError:<div class="gmail_extra"><br></div><div class="gmail_extra">Which, excluding the awful extra import statement, looks a lot like what you just suggested.<br></div><div class="gmail_extra">Thinking while I type... if I were to package all of that as ... say perhaps a class that no one ever makes an instance of ... I could get exactly what you propose in short order.<br>

<br></div><div class="gmail_extra">+1 the idea.<br>--<br></div><div class="gmail_extra">Vernon<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 23, 2013 at 1:29 AM, 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="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 22.04.2013 18:59, Michael Bayer wrote:<br>
><br>
> On Apr 22, 2013, at 12:44 PM, Dan Lenski <<a href="mailto:dlenski@gmail.com">dlenski@gmail.com</a>> wrote:<br>
><br>
>> Michael Bayer <mike_mp <at> <a href="http://zzzcomputing.com" target="_blank">zzzcomputing.com</a>> writes:<br>
>><br>
>>> On Apr 21, 2013, at 9:39 PM, Daniel Lenski <dlenski <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
>>><br>
>>>><br>
>>>> I *could* pass around a handle to the DB module along with the cursor<br>
>>>> itself, as you've suggested, but that seems redundant and error-prone<br>
>>>> to me.  To my mind, this is a small gap in the DBAPI design:<br>
>>>> (1) DBAPI does specify a set of module-dependent type objects<br>
>>>> against which column type objects are to be compared<br>
>>>> (2) DBAPI does specify a cursor object which will produce column<br>
>>>> type objects after a query is executed<br>
>>>> (3) DBAPI *doesn't* provide any way to get from the cursor object to<br>
>>>> the module-defined type objects, at least not without passing  around<br>
>>>> module-dependent object.<br>
>>><br>
>>> IMHO, the DBAPI is not meant to be used as a direct API within higher<br>
>> level application code; it only aims to<br>
>>> provide a consistent low-level API to a wide variety of databases.   It<br>
>> should always be framed within some<br>
>>> kind of abstraction layer within real-world application.  Therefore it<br>
>> should not concern/complicate<br>
>>> itself worrying about convenience accessors, this only makes it more<br>
>> difficult for DBAPI implementors,<br>
>>> leads to greater inconsistency between implementations, and makes it<br>
>> harder to test for compliance.<br>
>>><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 carrying<br>
>> around extra module-dependent state on their own.<br>
><br>
><br>
> well I will say that there is precedent for this specific request - the cursor.connection attribute is part of the spec, and is pretty harmless, and the spec also includes the option for the DBAPI exception classes to be attached onto the Connection, which you can see here: <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 we're sticking the module-level exception classes directly onto the connection (which I find kind of distasteful, but there it is), might as well put *all* module-level constants onto it.<br>


<br>
</div></div>I don't think we should clutter up the connection objects with<br>
module scope attributes that hardly ever get used.<br>
<br>
The exceptions are used a lot, so it makes sense to have them<br>
easily available via the connection object - even though I'm not<br>
sure whether that particular DB-API extension was such a<br>
good idea w/r to API design (it's one of those practicality beats<br>
purity things).<br>
<br>
Adding access to the database module via the connection object<br>
would allow to resolve all this. The problem<br>
with doing so is that you typically don't want the module<br>
object to be referenced directly by hundreds of objects in your<br>
application and you can also run into problems when reloading<br>
modules or (depending on how this is implemented) circular<br>
references.<br>
<br>
A method doing the lookup via the sys.modules dictionary<br>
could resolve those issues:<br>
<br>
database = connection.database()<br>
try:<br>
    cursor = connection.cursor()<br>
    cursor.execute(...)<br>
except database.DataError:<br>
    ...<br>
<br>
Thoughts ?<br>
<br>
--<br>
Marc-Andre Lemburg<br>
eGenix.com<br>
<br>
Professional Python Services directly from the Source  (#1, Apr 23 2013)<br>
>>> Python Projects, Consulting and Support ...   <a href="http://www.egenix.com/" target="_blank">http://www.egenix.com/</a><br>
>>> mxODBC.Zope/Plone.Database.Adapter ...       <a href="http://zope.egenix.com/" target="_blank">http://zope.egenix.com/</a><br>
>>> mxODBC, mxDateTime, mxTextTools ...        <a href="http://python.egenix.com/" target="_blank">http://python.egenix.com/</a><br>
________________________________________________________________________<br>
2013-04-17: Released eGenix mx Base 3.2.6 ...     <a href="http://egenix.com/go43" target="_blank">http://egenix.com/go43</a><br>
<br>
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::<br>
<br>
   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48<br>
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg<br>
           Registered at Amtsgericht Duesseldorf: HRB 46611<br>
               <a href="http://www.egenix.com/company/contact/" target="_blank">http://www.egenix.com/company/contact/</a><br>
<div class=""><div class="h5">_______________________________________________<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></div>