This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients christian.heimes, methane, pitrou, rhettinger, scoder, serhiy.storchaka, vstinner
Date 2017-09-13.19:49:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1505332152.82.0.350820872634.issue31336@psf.upfronthosting.co.za>
In-reply-to
Content
> Is it correct to call _PyType_Lookup() with an exception set?

The general rule of thumb is that it's not safe to call any user code with a live exception set, and lookups can call into user code.

I quickly looked through all occurrences (there aren't that many actually), and they all seem be be called from a context where a live exception would be wrong.

> Perhaps we should save a current exception before calling find_name_in_mro() and restore it after.

I thought about that, too, but it feels wrong. This just shouldn't be necessary. It's ok to save away exceptions in exception related code, but general purpose code shouldn't have to assume that it gets called with a live exception.

> Or just add assert(!PyErr_Occurred()) at the begin of find_name_in_mro().

That would catch the error at hand. The only concern is backwards compatibility. But it's easy to argue that it's the foreign code that is broken in this case (as show-cased by cElementTree) and clearly needs fixing if this occurs. An assert() seems like a reasonable way to catch this kind of bug, at least in a debug build.
History
Date User Action Args
2017-09-13 19:49:12scodersetrecipients: + scoder, rhettinger, pitrou, vstinner, christian.heimes, methane, serhiy.storchaka
2017-09-13 19:49:12scodersetmessageid: <1505332152.82.0.350820872634.issue31336@psf.upfronthosting.co.za>
2017-09-13 19:49:12scoderlinkissue31336 messages
2017-09-13 19:49:12scodercreate