On May 19, 2013 5:10 PM, "Vernon D. Cole" <vernondc...@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 welcome. > 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
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
