Re: A list of open points in the documentation
Daniele Varrazzo <[email protected]> Thu, 11 Feb 2010 11:03:44 +0000
| Newsgroups | gmane.comp.python.db.psycopg.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Feb 11, 2010 at 9:54 AM, Karsten Hilbert <[email protected]> wrote: > On Wed, Feb 10, 2010 at 09:03:54AM +0100, Federico Di Gregorio wrote: > >> > the psycopg documentation is almost finished. It can be previewed on >> > http://piro.develer.com/psycopg2-doc/ > > Thank you, Piro ! > >> > 3. DBAPI says that scroll() should raise IndexError. Psycopg raises >> > ProgrammingError instead. I'd say this is a bug, but maybe it's too >> > late to be fixed. Shall we keep it this way? Shall I point out the >> > discrepancy between dbapi and psycopg in the docs or keep it quiet? >> >> This is surely a bug but I fear to break a lot of stuff out there fixing >> it. We should probably add a "strict dbapi" flag that if enabled makes >> psycopg to do the right thing. > > +1 > > Probably add a log message, too, saying it should be fixed. I had a very thorough review of what's in psycopg2, and maybe this is the only point where the implementation is not *entirely* respected. I don't think the behaviour of the existing DBAPI adapters is so homogeneous that anybody would be blindly relying on it and thus would be bothered by the problem. Conversely, because this error is raised in a very specific point, the cur.scroll() method, chances are that who is using it has done his own tests and is already dealing with the right exception. Is not that it happens in a remote edge case: if you are using scroll(), the second think you would try is "cur.scroll(1000 * 1000)" and you would immediately know what to do. If the point has never come up I think is because scroll() is not the most used method around. So, I think changing the exception would only be a problem for people already using the method and dealing with it (who have probably already figured out that catching (IndexError, ProgrammingError) is a good idea) and not such a huge win for anybody else, who are now warned about what to do. We would add the "strict mode" only for this small glitch which is /something else/ people should think about... for me it would be overkilling - just multiplying code paths while not being an huge win. I added a note in the documentation about the discrepancy and how to cope with it (http://piro.develer.com/psycopg2-doc/cursor.html#cursor.scroll): I think this is more than enough for both existing and new psycopg users. -- Daniele