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

[Vernon D. Cole]

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

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.

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.

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


On Sat, May 18, 2013 at 8:22 PM, Daniele Varrazzo <
daniele.varrazzo at gmail.com> wrote:

> On Sat, May 18, 2013 at 9:29 AM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
> > So, here is the thing.  I want you to take the time to make your database
> > driver "*way, way* more complicated" by supporting the SQL format I must
> > use, which is 'qmark'.
>
> Aaahhh... is it that what you want? If what you wanted is a psycopg
> talking qmark, why on the earth haven't you asked for that? Why
> instead are you asking the DBAPI to rule that every db driver must
> implement qmark?
>
> There: just released qmarkpg, allowing using qmark and named
> parameters with psycopg:
>
>  - Source: https://github.com/dvarrazzo/qmarkpg
>  - PyPI: https://pypi.python.org/pypi/qmarkpg/
>
> This is not a mock. The module passes the DBAPI test suite (2PC included).
>
> Nobody in my about 10 years of frequentation of the psycopg mailing
> list has ever asked psycopg to implement qmark/named. I repeat it:
> this is a need nobody has ever expressed. And believe me we have been
> asked for a lot of things.
>
> This module is the proof that qmark or not qmark syntax is a
> non-issue: converting across types is a trivial operation. Writing a
> wrapper module is a solution infinitely superior to any
> module/connection/cursor writable attribute dancing; perfectly thread
> safe and 100% backward compatible.
>
> My impression from this long thread is that we are in front of
> bikeshedding in its purest form: I haven't read a rationale yet to
> justify the rewrite of *every query* written in Python against MySQL,
> PostgreSQL and god knows what other database server. The justification
> has been just a tad more than "we like the ?". The feature
> specification is "let's copy Java".
>
> Well, I've looked into that too: JDBC specifies *only* qmark, not
> named. Named is only supported by *a different* object (a wrapper, I
> understand): JDBC does not define a grammar where both qmark and named
> can be used. And unsurprisingly so: the grammar is ambiguous:
>
> cur.execute("select $$a ? and a :foo$$", args)
>
> This is a valid postgres query. If args is an object implementing
> Mapping and Sequence ABCs there's no way to disambiguate that. Now go
> on and tell me that we could double the ? even when the :foo are used:
> we are making up that syntax now, because JDBC hasn't event tried. Oh,
> and in the placeholder with unary "?" operator (valid in postgres)
> "???": is the operator prefix or suffix?
>
> Any driver implementing both positional and named arguments will face
> the ambiguities of a grammar the proponents have not specified: a
> problem that format/pyformat don't have.
>
> My bottom line is that it is provable that a spec mandating
> qmark/named is broken,  and psycopg will never implement it: not only
> for its technical inferiority but above all because there is no real
> request for it, and people who believe they need that can obtain the
> same result in trivial ways without bothering the rest of the world.
>
> -- Daniele
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130519/f2b8dcf0/attachment.html>