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

Daniele Varrazzo daniele.varrazzo at gmail.com
Sun May 19 21:01:28 CEST 2013

On May 19, 2013 5:10 PM, "Vernon D. Cole" <vernondcole at gmail.com> wrote:
> Dear Daniele:
>  I am a bit confused.  Two posts ago you said that supporting other
parmamstyle values would be "*way, way* more complicated".  Now you say: "
qmark or not qmark syntax is a non-issue: converting across types is a
trivial operation."

It is uselessly painful maintaining a driver allowing paramstyle switching
and very hard developing a program making use of it. What has been very
easy is wrapping a dbapi module with another dbapi module that support *a
single* paramstyle (actually two: one positional and one mapped). qmarkpg
does no attempt to support pyformat.

> Clearly you are against the "two paramstyles are mandatory, others are
optional" rule.  But I cannot quite make out whether you are against
implementing it because it is too hard, or because it is too easy.

Because it's too hard inside a single module and laughably easy outside if
it, keeping previous module users happy. If I'm failing making this point
understood I must be a total lamer at explainations. Or I am being
thoroughly trolled.

> My own experience, as a developer who has already done this, is that the
job is somewhere in the middle -- somewhat complex.  It took me a day or
two to write the code and the tests.  Not a job to give a beginner, but not
a real head breaker either.
> You also state that the modification is not needed because it has never
been requested by one of *your* users.
> <<Please avert your eyes while I remove my Windows-driver-developer shirt
and put on my Linux-django-developer shirt>>
> ----
> Dear Daniele:
>   I am a software engineer who is developing a system to aid in the
eradication of polio from the earth. Our company uses django, and
PostgreSQL databases on Ubuntu servers and workstations, using psycopg2.
We now have a need to interface our data with SQL Server databases and
analysis tools used by other agencies.  In order to do so, I am updating a
db-api driver I maintained when I worked for a Microsoft-only shop, and
have begun working with the core developers of django to better
inter-operate with SQL Server.
>   A discussion on the subject of 'format' paramstyle with my mentors on
the django-developers group revealed that they do _not_ favor the style,
and in fact it causes problems by its interaction with the Python '%'
operator.  They would welcome the opportunity to simply their lives by
gradually moving to 'qmark' and 'named' styles, which do not suffer from
'%' pollution.
>   Please use your time and influence to make this possible for our
premier database system.  Will this method of communication be sufficient,
or should I open a trouble ticket addressing the issue?
>   Your sincere user,
> Vernon Cole
> software engineer
> eHealthAfrica.org
> ------
> <<\shirt>>
> Now, you have had a user request.

Dear Vernon,

I know the %s placeholders may be a little confusing: they are used because
psycopg predates the parameter passing feature of the postgres client
library. This doesn't save implementation troubles to psycopg: internally
it doesn't use the python % operator (because py3 doesn't offer it for
bytes - also note that psycopg2 predates the dbapi on py3 and Unicode
queries support, for which the dbsig hasn't had any discussion). On the
other hand recent research has shown that even if %s may have chosen by
accident (or may not: fog is a clever guy) it offers the only way to
support both positional and mapped parameters support, whereas other
adapters offer only one of the style (more precisely: other adapters just
offer whatever the underlying client library offer: ? for sqlite, :name for
Oracle etc. Had psycopg done the same it would have been $n).

Even if Psycopg authors wanted to review the placeholder syntax it would
result in serious backward incompatibility (meaning 100% incompatibility!)
with already written code: you can bet your favourite grandma we would be
forked in no time! We have also been requested to drop support for
parameters passed as dicts and only implement ?, at which I believe there
would be a Kickstarter project to hire a couple of hitmen and send them
where I live (and I'd give them 15 quids).

Incidentally I've started a project to support qmark and named placeholder:
please check the qmarkpg project on pypi and github. It is a psycopg
wrapper and it inherits all its features. The project is recent but not
less mature than what psycopg would be if we changed placeholders
internally. Please test it: patches and bug reports (both on github) are

> 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.

-- Daniele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130519/2cd2a33c/attachment-0001.html>

More information about the DB-SIG mailing list