Skip site navigation (1) Skip section navigation (2)

Re: Confusion over Python drivers {license}

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Kevin Ar18 <kevinar18(at)hotmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Confusion over Python drivers {license}
Date: 2010-02-11 04:13:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Kevin Ar18 wrote:
> Based on that, I guess my question is what would it have taken to have 
> picked one of BSD/MIT projects and working with those people instead?  
> In other words, what key things affected the decision for psycopg?  
> What areas is it so far ahead in or that would have just been too much 
> work to fix in the other implementations?

A lot of it as I see it is plain old fashioned popularity resulting from 
long sustained development.  psycopg has been around since 2001, the 
current version is already compatible with SQLAlchemy, Django, Zope, 
PyDO, and it's integral to the large Python/PostgreSQL toolchain from 
Skype including tools like Londiste.  When something is supported in 
that many places, and the main complaints are its license and 
documentation rather than its code, I know I'm not going to start by 
assuming I should just hack on somebody else's code to try and replace 
it just because their license is a little better.  And I'd consider 
BSD/MIT only a little better than the LGPL.

That sort of bad decision making is how we got to so many abandoned 
Python drivers in the first place.  If everybody who decided they were 
going to write their own from scratch had decided to work on carefully 
and painfully refactoring and improving PyGreSQL instead, in an 
incremental way that grew its existing community along the way, we might 
have a BSD driver with enough features and users to be a valid 
competitor to psycopg2.  But writing something shiny new from scratch is 
fun, while worrying about backward compatibility and implementing all 
the messy parts you need to really be complete on a project like this 
isn't, so instead we have a stack of not quite right drivers without any 
broad application support.

(Aside:  I have a bit of vocabulary I regularly use for this now.  
Open-source projects that just ignore working on an existing stack of 
working implementations, to instead start from scratch to build 
something of questionably improved fanciness instead regardless of its 
impact on backward compatibility and the existing userbase, have in my 
terminology "PulseAudioed" the older projects).

The gauntlet I would throw down for anyone who thinks there's a better 
approach here is to demonstrate a driver that has working support going 
back to Python 2.4 for any two of the apps on my list above.  Get even 
that much of a foothold, and maybe the fact that yours is more Pythonic, 
cleaner, or better licensed matters.  Until then, working apps have to 
be the primary motivation for what to work on here, unless there's a 
really terrible problem with the driver.  The existing psycopg license 
and the web site issues were in combination enough to reach that level 
of total issues for a number of people.  With the news from Federico 
that a license improvement is approaching and signs of major 
documentation improvements, that problem seems like it will soon be 
solved as far as I'm concerned.  When someone manages to make their 
alternative driver a prerequisite for an app I need, only at that point 
will that driver show back up on my radar.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2010-02-11 04:21:24
Subject: Re: Postgres Triggers issue
Previous:From: Tom LaneDate: 2010-02-11 04:07:57
Subject: Re: Avoiding bad prepared-statement plans.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group