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.
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...
import adodbapi
import adodbapi.apibase as api
...
try:
cursor = connection.cursor()
cursor.execute(...)
except api.DataError:
Which, excluding the awful extra import statement, looks a lot like what
you just suggested.
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.
+1 the idea.
--
Vernon
On Tue, Apr 23, 2013 at 1:29 AM, M.-A. Lemburg <m...@egenix.com> wrote:
> On 22.04.2013 18:59, Michael Bayer wrote:
> >
> > On Apr 22, 2013, at 12:44 PM, Dan Lenski <dlen...@gmail.com> wrote:
> >
> >> Michael Bayer <mike_mp <at> zzzcomputing.com> writes:
> >>
> >>> On Apr 21, 2013, at 9:39 PM, Daniel Lenski <dlenski <at> gmail.com>
> wrote:
> >>>
> >>>>
> >>>> I *could* pass around a handle to the DB module along with the cursor
> >>>> itself, as you've suggested, but that seems redundant and error-prone
> >>>> to me. To my mind, this is a small gap in the DBAPI design:
> >>>> (1) DBAPI does specify a set of module-dependent type objects
> >>>> against which column type objects are to be compared
> >>>> (2) DBAPI does specify a cursor object which will produce column
> >>>> type objects after a query is executed
> >>>> (3) DBAPI *doesn't* provide any way to get from the cursor object to
> >>>> the module-defined type objects, at least not without passing around
> >>>> module-dependent object.
> >>>
> >>> IMHO, the DBAPI is not meant to be used as a direct API within higher
> >> level application code; it only aims to
> >>> provide a consistent low-level API to a wide variety of databases. It
> >> should always be framed within some
> >>> kind of abstraction layer within real-world application. Therefore it
> >> should not concern/complicate
> >>> itself worrying about convenience accessors, this only makes it more
> >> difficult for DBAPI implementors,
> >>> leads to greater inconsistency between implementations, and makes it
> >> harder to test for compliance.
> >>>
> >>
> >> I get your point about not crufting up DBAPI with a bunch of high-level
> >> features that will need to be reimplemented for each module...
> >>
> >> But this seems to me precisely the kind of feature that *should* exist
> at
> >> this level, because it makes it easier for higher-level interfaces to
> >> manipulate the underlying database objects in a generic way without
> carrying
> >> around extra module-dependent state on their own.
> >
> >
> > 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:
> http://www.python.org/dev/peps/pep-0249/#optional-db-api-extensions. 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.
>
> I don't think we should clutter up the connection objects with
> module scope attributes that hardly ever get used.
>
> The exceptions are used a lot, so it makes sense to have them
> easily available via the connection object - even though I'm not
> sure whether that particular DB-API extension was such a
> good idea w/r to API design (it's one of those practicality beats
> purity things).
>
> Adding access to the database module via the connection object
> would allow to resolve all this. The problem
> with doing so is that you typically don't want the module
> object to be referenced directly by hundreds of objects in your
> application and you can also run into problems when reloading
> modules or (depending on how this is implemented) circular
> references.
>
> A method doing the lookup via the sys.modules dictionary
> could resolve those issues:
>
> database = connection.database()
> try:
> cursor = connection.cursor()
> cursor.execute(...)
> except database.DataError:
> ...
>
> Thoughts ?
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Apr 23 2013)
> >>> Python Projects, Consulting and Support ... http://www.egenix.com/
> >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> ________________________________________________________________________
> 2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> http://www.egenix.com/company/contact/
> _______________________________________________
> DB-SIG maillist - DB-SIG@python.org
> http://mail.python.org/mailman/listinfo/db-sig
>
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
