Vernon Cole wrote: > On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer > <mike...@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 context. 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. Right. -- Marc-Andre Lemburg eGenix.com 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 http://www.egenix.com/company/contact/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
