M.-A. Lemburg wrote:
>  
>  Just wanted to remind you that the deadline for the last call is
>  this Friday.

Reminder: Friday is last call for this round. The spec then receives all
updates to produce a "final draft" for consensus sign-off on March 26.
The new spec is posted on March 29.

>  The latest version of the proposal can be found at:
>  
>          http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html
>  
>  Feel free to comment on it. Greg Stein has created an annotated
>  version which is available at:
>  
>          http://www.lyra.org/greg/anno-DatabaseAPI-1.1.html

I have updated the annotated version to match 1.1a7 (Marc's most recent
version).

>  Some things still open for discussion (some of which may go into
>  1.2):
>  
>  · punting dbi (by folding its features into the database modules
>    themselves)

Let's do this. This would clean things up quite a bit. I do not believe
the dbi thing provided all the benefits that it could have. And compared
to the cost, we should nuke it.

>  · developing a few more common sets of types, e.g. for passing
>    raw data, monetary data, etc. which may be used by the interface
>    modules to bind the correct type

I'm somewhat ambivalent here.

What might be interesting is to define how an object must respond, and
leave it to implementors to use a class instance or builtin type. For
example:

class MyDBValue:
  pass
v = MyDBValue()
v.dbtype = 'RAW'
v.value = 'abcdef'

The DBAPI would specify that "object.dbtype == 'RAW'" means that the
object represents a RAW value, which is a read-buffer in the .value
attribute.

== 'CURRENCY' means a monetary unit where .value is an integer or float
or something.

etc.

>  · designing a common package layout for the database packages

If we nuke dbi, then a package is not required. However, I believe it
would be fair to spec a "typical" pair of .py and .so modules (e.g.
somedb.py and _somedb.so).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/