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