On May 20, 2013, at 6:44 PM, Daniele Varrazzo <daniele.varra...@gmail.com> wrote:
> > So I believe there is really no need for the spec to restrict > placeholder styles: you may come out with two flavours of the specs: > kinda dbapi3-human and dbapi3-orm, the latter demanding qmark only; > but because you can mechanically convert any placeholder to qmark in a > wrapper module I see no reason for the dbapi to rule on that and cut > out the realistic use cases of direct users of a dbapi module (at the > same time forcing an unworkable upgrade path). SQLAlchemy, Django, > etc. may just use psycopg2 as: > > import qmarker > import psycopg2 as _psycopg2 > psycopg2 = qmarker.qmark_module(_psycopg2) > # your magic here It is obvious that any number of wrappers can be made to make the paramstyle act like anything- the discussion here is only about a change for a new DBAPI3 specification. Again, SQLAlchemy has no need for such a wrapper as it already essentially *is* one, and if and when a DBAPI3 spec ever came out we will still be supporting DBAPI2 for decades seeing that we support many DBAPIs that haven't gotten updated in months/years, so again, nothing is changing in the slightest for SQLAlchemy. The discussion is strictly about attempting to improve a spec that for some inexplicable reason defines six different ways to do the same thing for no apparent reason - and if this one simple and glaring wart can't be improved upon, then I am very pessimistic about the reality of a DBAPI3 spec; we might as well just keep adding more optional bells, whistles and accessors to DBAPI2. There are of course upgrade paths if a real DBAPI3 with backwards incompatible changes came out, backwards incompat ible upgrade paths are a basic fact of software development which we all must deal with every day. In this case, users of the new spec import from a new namespace, or add new arguments to how they connect, simple as that - no existing users need to be impacted in any way. Backwards incompatible changes are the only way you can remove cruft from an API. But if we're deciding that cruft removal is not an option, then the whole discussion here has no point. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
