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.varra...@gmail.com> wrote: > On Sat, May 18, 2013 at 9:29 AM, Vernon D. Cole <vernondc...@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 >
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
