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

Daniele Varrazzo daniele.varrazzo at gmail.com
Mon May 20 11:35:09 CEST 2013

On Sun, May 19, 2013 at 8:01 PM, Daniele Varrazzo
<daniele.varrazzo at gmail.com> wrote:
> On May 19, 2013 5:10 PM, "Vernon D. Cole" <vernondcole at gmail.com> wrote:
>> Please don't just take your ball and go home.  That will not stop the ball
>> game, but it will rain on it.  Work with us.
> I have expressed my views about how the idea of switchable placeholders is
> ill thought and why qmark and named don't play well together. If dbapi
> decided to make qmark mandatory qmarkpg would be our dbapi3 driver while
> psycopg would stay dbapi2.

Vernon, because I know my communication skills are not the best and I
probably cut my sentences too short: don't see my position as "I'm
taking the ball home and not playing with you anymore". You have
discussed two solutions in this thread and on these I have my

- a single placeholders style would be ok but who has proposed it
should be specify it in a complete and unambiguous way, not first
decide to go that way and then hope in a miracle

- a switchable grammar is bad, and who has proposed it should be aware
that makes thread safety at level 2 (sharing the connection)

- if a non-backward compatible road is decided, an update path to
survive the period of coexistence of the two standards as has been
with py2.6 and 2to3 in the long road for py3: none of that has been

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.

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.

So, please, be responsible: the dbsig has too little active users, I
believe really too little for the amount of responsibility it brings.
You have the duty to be more responsible than this, throwing balls of
mud at the wall and see if they stick will only cause problems at
massive scale and most likely will leave dbapi3 discredited and

-- Daniele

More information about the DB-SIG mailing list