[Python-bugs-list] [ python-Bugs-462064 ] Python 2.2 ignores execptions from cmp()

noreply@sourceforge.net noreply@sourceforge.net
Sun, 16 Sep 2001 20:48:37 -0700


Bugs item #462064, was opened at 2001-09-16 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=462064&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.2 ignores execptions from cmp()

Initial Comment:
In Python 2.2a3, any exceptions set in the compare
function
of an extension module are not handle properly.

In the following example, an exception will be raised
during
the comparison.  I am including output from both Python
2.1
and 2.2.  In Python 2.2 there is no traceback and when
another exception is raised, the error message from the
exception raised during the comparison is printed
(without
any traceback information), not the actual exception.

------------------
Python 2.1.1 (#4, Aug 13 2001, 18:25:49) [C] on
unixware7
Type "copyright", "credits" or "license" for more
information.
>>> import libpq
>>> cx = libpq.PQconnectdb('host=/tmp')
>>> v = cx.version
>>> v
PostgreSQL 7.1.3 on i586-sco-sysv5uw7.1.1, compiled by
cc
>>> v == ''
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: Ivalid format for PgVersion construction.
>>>
------------------
Python 2.2a3+ (#1, Sep 15 2001, 18:44:03) [C] on
unixware5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import libpq
>>> cx = libpq.PQconnectdb('host=/tmp')
>>> v = cx.version
>>> v
PostgreSQL 7.1.3 on i586-sco-sysv5uw7.1.1, compiled by
cc
>>> v == ''
0
>>> a  # This should raise a NameError exception.
ValueError: Ivalid format for PgVersion construction.
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'a' is not defined
>>>
------------------


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-16 20:48

Message:
Logged In: YES 
user_id=6380

There's no FAQ for extension builders -- nobody looks there.
I hope people will find this bug report though. I'll close
it as you request.

I'm not sure I understand your last remark. A coercion
operation can raise an exception too, by returning -1. 
(Although it is more customary to say you can't do the
coercion by returning 1.)

I realize that these APIs aren't always clearly documented
(I don't write the docs and I don't use them :-( ). But it
sounds like you are not reading enough existing code to look
for examples?!

----------------------------------------------------------------------

Comment By: Billy G. Allie (ballie01)
Date: 2001-09-16 20:36

Message:
Logged In: YES 
user_id=8500

The code is in a classic three-way compare.  Based on your
response, I changed the code to always return -1 when an
exception is raised.  The code was previously returning 1. 
Apparently, Python 2.0 and 2.1 would recognize the exception
no matter what was returned by the comparison routine. 
Python 2.2 only checks for an exception when -1 is returns.

Perhaps this should be noted in a FAQ?

Thanks for the response.  This bug report can be closed.

BTW, in order to detect that the coercion from a string (or
number) to a PgVersion object failed, I had to chanve the
coercion return a 'special' PgVersion object that contained
the error information (retrieved by PyErr_Fetch()).  The
comparison routine recoginizes this 'special' PgVersion
object and restores the error information via PyErr_Restore.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-16 19:41

Message:
Logged In: YES 
user_id=6380

Sorry, I can't reproduce this. I have tried by adding
comparison routines that return an error to the spamlist
type of the xxsubtype module in 2.2. The error gets raised
properly.

Can you upload the source of the comparison routine(s)
involved? Is it a rich comparison or a classic three-way
compare? (I realize I could track down the code you used
myself, but I don't know Postgres at all, so it would be a
lot more work for me than for you.)

The symptom you report, by the way, means that somewhere an
exception is set but the proper error return value
(typically NULL or -1) is not returned. It's possible that
the code you used is subtly wrong, but it's also possible
that your code triggers a path through the 2.2 comparison
code that has a bug in it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=462064&group_id=5470