Author belopolsky
Recipients belopolsky, brett.cannon, nnorwitz, zotbar1234
Date 2008-03-16.16:33:49
SpamBayes Score 0.000984801
Marked as misclassified No
Message-id <1205685230.61.0.727774431905.issue2291@psf.upfronthosting.co.za>
In-reply-to
Content
I thought some more about this issue and the current behavior seems 
wrong and potentially dangerous.  Consider the following code:

class x: 
    pass 
class y(x): 
    pass 
try: 
    raise y 
except y: 
    print "a" 
except: 
    print "b" 

It prints 'b'. Now, suppose in preparation for 3.0 transition someone 
adds "__metaclass__ = type" to the module with that code.  The result: 
it prints 'a'.  Since the difference in behavior is in error handling 
code, which in my experience is often not thoroughly tested, the bug 
introduced by a seemingly innocuous move from old to new style classes 
is likely to trigger in the worst possible moment.  (For example a wrong  
roll-back logic is applied after a failed database commit.)

My understanding is that the current logic of bypassing the subclass 
check in PyErr_GivenExceptionMatches in the case of new style class 
which is not a subclass of BaseException, is designed to support string 
exceptions.   Maybe a better choice would be to exclude only string 
subclasses from a subclass check.

I will submit a patch if others agree that this approach is worth 
considering.
History
Date User Action Args
2008-03-16 16:33:51belopolskysetspambayes_score: 0.000984801 -> 0.000984801
recipients: + belopolsky, nnorwitz, brett.cannon, zotbar1234
2008-03-16 16:33:50belopolskysetspambayes_score: 0.000984801 -> 0.000984801
messageid: <1205685230.61.0.727774431905.issue2291@psf.upfronthosting.co.za>
2008-03-16 16:33:49belopolskylinkissue2291 messages
2008-03-16 16:33:49belopolskycreate