[DB-SIG] Some obscurity with paramstyle
mal at egenix.com
Mon Jul 18 09:52:02 CEST 2011
Vernon Cole wrote:
> On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer <mike_mp at zzzcomputing.com>wrote:
> >Is there a path to changes being made in the DBAPI? i.e. would there be a
>> DBAPI 3 ?
> That possibility has been discussed before, and is particularly timely given
> that it is impossible to write a PEP 249 compliant module in Python 3. [For
> example, the PEP states that an Error exception "must be a subclass of the
> Python StandardError" -- which Python 3 does not support.]
> Marc-André Lemburg (the author of PEP 249) came out against an update --
> mostly due to performance reasons.
Not sure, where you read that :-)
I'm not opposed to a DB API 3, but since there are only a few
things on the table for DB API 3 and the adoption of Python 3.x
has just started, so it's not all that urgent.
> This is understandable, because his
> company produces a very efficient db api module. The features which have
> been suggested for a possible DBAPI 3.0 would add some significant overhead
> in some situations. The worry is real. Compare the mxDateTime module (also
> from Mark-Andre's company) with the (newer) standard datetime module, and
> you will see that datetime is a slow dog. (I use it anyway.)
> On the other hand, GVR is in favor of an update. When MAL suggested that
> some ease-of-use improvements (such as named columns) would make
> implementation of a module more difficult, The BDFL replied that we should
> make things easier for the user, not the module author. [ I am relying on my
> memory -- my copy of the exchange got deleted and I am too lazy to look it
> up in the archive. ;) ]
> So Yes, there are a TON of new language constructs which could be addressed
> in an updated API version. The use of a cursor as an iterator is supported
> by most DB API modules, but not mentioned in PEP 249.
Please have a look again.
Note that we have added quite a few (optional) extensions to the
DB API 2 in recent years, so even though the version number and
the base set of required features hasn't changed, there are many
feature already addresses in the DB API.
> A cursor and/or a
> connection should probably be context managers, so that they will work in a
> "with" statement.
This is was discussed before and it should probably go into
the DB API in some form.
I'm no particular fan of hiding transactions in context
managers, though. In practice this often causes problems, since
you usually want to apply error handling logic in case of
problems, other than simply issuing a .rollback().
Another problem is that the connections used in a with
statement will usually have already started a transaction
before entering the context, so the .rollback() would
remove more than just the things added in the with
There's also the problem of intuitive use: some users will
likely expect the connection to also be closed when leaving
the context - much like what happens with files.
The case for having cursors automatically closed by
is not problematic
> There should be a better definition of how BINARY fields
> work with byte() data.
Professional Python Services directly from the Source (#1, Jul 18 2011)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new 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
More information about the DB-SIG