[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

[Michael Bayer]

On May 20, 2013, at 5:35 AM, Daniele Varrazzo <daniele.varrazzo at gmail.com> wrote:

> 
> What I ask is, everybody, please, show some responsibility. Think
> about the consequence of your decisions. The dbapi is used by
> *everybody* who uses python and any database. Michael: your only
> observations are "the feature X (or its abolition) would make
> SQLAlchemy n lines of code smaller". Well, guess what, proposing to
> sacrifice useful features because of use case is absolute selfishness.

Sorry, I don't normally say things like this but to accuse me of "selfishness" is really ridiculous.  SQLAlchemy is hardly at all affected whether or not DBAPI has two or eighteen paramstyles, as I've said, we can deal with anything, we already deal with dozens of inconsistencies at many levels and the paramstyle issue is one of the most trivial, it is very easy to code around - which is why it's all the more absurd that DBAPI authors themselves would express vast reservation about a change on their end, as it is similarly not a big deal no matter what the paramstyle is.

My agenda here is that, since we're talking about improving the DBAPI, to suggest how I really think it can be improved, and seeing as this one little part of DBAPI is actually being discussed to be improved, I've made my suggestion which is, to remove the unnecessary number of paramstyles and standardize on just two.   If it turns out that all the DBAPI authors simply cannot agree as to which two styles to choose and we stay with six, then that is DBAPI's unfortunate loss, not SQLAlchemy's.


> 
> My main responsibility is for psycopg2 users, but I'm not against the
> dbapi evolution, and I'm not against working (as I've always done, for
> free) writing code to meet the expectation of a solid and
> standard-compliant driver. My choice of responsibility is to meet the
> request of a dbapi3 to use a non-backward-compatible placeholder style
> by developing a dbapi3 compliant wrapper module, leaving Psycopg
> dbapi2 compliant, and to talk you out of switchable placeholders. Mine
> is the only suggestion of an upgrade path that has been proposed in
> this thread.

Nobody is debating that at all, psycopg2 can take whatever upgrade path it chooses.   I was under the impression we were just talking about a spec here.