[DB-SIG] Abstraction layer confusion, ULA (was Re: Database Abstraction in Python)

Jonathan Franz jfranz at neurokode.com
Mon Apr 18 16:51:20 CEST 2005

> Hmm, I don't see how the DB API limits any module writer
> from adding new features to their implementation.
> In fact, many authors have added features to their implementation
> and as a result we have added a special section to the DB API
> to make sure that these features use standardized semantics.

Ack! I guess my definition of a standard is different than yours - I 
would see all extensions either made part of the core standard, or 
removed from the document entirely.  Optional features just confuse the 

> It would really help if you could be more specific about those
> lacking features.
> The only feature which I'd really like to see in DB API 3.0
> is a standard way to tell the module how to map database types
> to Python types and vice-versa.

That is one of the main ones I want/need for PDO, see my response to 
Anthony for others.

> My main concern is that you are trying to reuse the term "DB API"
> in a way which historically doesn't make sense: the DB API
> has always been a very simple API specification focussed on
> very basic database building blocks. The goal was to make
> it easy for module writers to build modules which adhere to the
> spec and to make it easy for users to write code on top of it.
> Think of it as middleware.

Ah, that makes sense, its a naming-and-scope thing.  OK.

> If you believe that we need to add features to the DB API spec
> to make the implementation of an abstraction layer easier,
> we can discuss this aspect.

Perfect, that is all I request!  Hopefully and/all added features that 
would make abstraction easier would also be useful for the application 
writer who writes directly to the spec himself, and for those who write 
app-specific abstractions.

> If you would like to see e.g. PDO or a similar package
> in Python's standard lib, that's a different discussion.

Whatever the standard ULA is/becomes, that should be suggested for the 
stlib, but only after it matures.

More information about the DB-SIG mailing list