> However by being *VERY* perverse, I was able to reproduce the above > error by overwriting AttributeError with some other exception class (say > SyntaxError): > AttributeError = SyntaxError > Then your code will be will produce a real AttributeError, but miss it > because (despite the spelling) it checks for a SyntaxError,
Yes ... this would be some kind of criminal joke > > Question... I don't know what contract.py is, but could it be doing > something that *bad*? No. I've searched the source for "AttributeError" and it appears only in except clauses. contracty.py is a library that adds Eiffel-like "design-by- contract" (DBC) to Python. Precisely, I can add preconditions (and postconditions) about the arguments into the methods docstring. These are checked at runtime (and appear in the epydoc docu.) This is a great thing I never want to miss anymore (and it was working fine for some months now.) (See http://www.wayforward.net/pycontract/ ) When the problem appears, contract.py is doing a pre-condition check. > You could check py printing AttributeError and see what it really is. > In my case it's: > >>> print AttributeError > exceptions.SyntaxError > > Gary Herron > > P.S.: Anyone who does this kind of thing is a danger to society. May > their finger fall off before they get a chance to distribute such a program. :-) @Tijs: I think when re-raising, the backtrace will always point to the line where it was re-raised but not to line 1265. (Or can we re-raise an exception so that it preserves the backtrace of the "original" exception?) --- I'm speculating about there's a misleading backtrace. Maybe another exception happens, but somehow using the obsolete exc_info of the last exception (the AttributeError). I remember about some way to clear the exc_info, maybe this must be added into contract.py? I'll find it out, or a debugger session this night will help (I'll post again) Ruben -- http://mail.python.org/mailman/listinfo/python-list
