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 things.
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.
_______________________________________________
DB-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/db-sig
