<div dir="ltr"><div><div><div>Dear Daniele:<br><br></div> 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."<br>
<br></div>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.<br>
<br></div>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. <br>
<div><div><br>You also state that the modification is not needed because it has never been requested by one of *your* users. <br><br><<Please avert your eyes while I remove my Windows-driver-developer shirt and put on my Linux-django-developer shirt>><br>
----<br></div><div>Dear Daniele:<br></div><div> 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. <br>
</div><div> 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.<br>
</div><div> 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?<br></div><div>
Your sincere user,<br></div><div>Vernon Cole<br></div><div>software engineer<br></div><div>eHealthAfrica.org<br></div><div>------<br></div><div><<\shirt>><br></div><div>Now, you have had a user request.<br>
<br>
</div><div>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.<br>--<br></div><div>Vernon Cole<br><br></div><div> <br></div><div><div><div><div class="gmail_extra">
<div class="gmail_quote">On Sat, May 18, 2013 at 8:22 PM, Daniele Varrazzo <span dir="ltr"><<a href="mailto:daniele.varrazzo@gmail.com" target="_blank">daniele.varrazzo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Sat, May 18, 2013 at 9:29 AM, Vernon D. Cole <<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>> wrote:<br>
> So, here is the thing. I want you to take the time to make your database<br>
> driver "*way, way* more complicated" by supporting the SQL format I must<br>
> use, which is 'qmark'.<br>
<br>
</div>Aaahhh... is it that what you want? If what you wanted is a psycopg<br>
talking qmark, why on the earth haven't you asked for that? Why<br>
instead are you asking the DBAPI to rule that every db driver must<br>
implement qmark?<br>
<br>
There: just released qmarkpg, allowing using qmark and named<br>
parameters with psycopg:<br>
<br>
- Source: <a href="https://github.com/dvarrazzo/qmarkpg" target="_blank">https://github.com/dvarrazzo/qmarkpg</a><br>
- PyPI: <a href="https://pypi.python.org/pypi/qmarkpg/" target="_blank">https://pypi.python.org/pypi/qmarkpg/</a><br>
<br>
This is not a mock. The module passes the DBAPI test suite (2PC included).<br>
<br>
Nobody in my about 10 years of frequentation of the psycopg mailing<br>
list has ever asked psycopg to implement qmark/named. I repeat it:<br>
this is a need nobody has ever expressed. And believe me we have been<br>
asked for a lot of things.<br>
<br>
This module is the proof that qmark or not qmark syntax is a<br>
non-issue: converting across types is a trivial operation. Writing a<br>
wrapper module is a solution infinitely superior to any<br>
module/connection/cursor writable attribute dancing; perfectly thread<br>
safe and 100% backward compatible.<br>
<br>
My impression from this long thread is that we are in front of<br>
bikeshedding in its purest form: I haven't read a rationale yet to<br>
justify the rewrite of *every query* written in Python against MySQL,<br>
PostgreSQL and god knows what other database server. The justification<br>
has been just a tad more than "we like the ?". The feature<br>
specification is "let's copy Java".<br>
<br>
Well, I've looked into that too: JDBC specifies *only* qmark, not<br>
named. Named is only supported by *a different* object (a wrapper, I<br>
understand): JDBC does not define a grammar where both qmark and named<br>
can be used. And unsurprisingly so: the grammar is ambiguous:<br>
<br>
cur.execute("select $$a ? and a :foo$$", args)<br>
<br>
This is a valid postgres query. If args is an object implementing<br>
Mapping and Sequence ABCs there's no way to disambiguate that. Now go<br>
on and tell me that we could double the ? even when the :foo are used:<br>
we are making up that syntax now, because JDBC hasn't event tried. Oh,<br>
and in the placeholder with unary "?" operator (valid in postgres)<br>
"???": is the operator prefix or suffix?<br>
<br>
Any driver implementing both positional and named arguments will face<br>
the ambiguities of a grammar the proponents have not specified: a<br>
problem that format/pyformat don't have.<br>
<br>
My bottom line is that it is provable that a spec mandating<br>
qmark/named is broken, and psycopg will never implement it: not only<br>
for its technical inferiority but above all because there is no real<br>
request for it, and people who believe they need that can obtain the<br>
same result in trivial ways without bothering the rest of the world.<br>
<span class=""><font color="#888888"><br>
-- Daniele<br>
</font></span></blockquote></div><br></div></div></div></div></div></div>