This may be related to the changes in https://bugs.python.org/issue42246.
Could you open a new issue and add Mark Shannon to it if that turns to be
the case?
Pablo
On Mon, 11 Jan 2021 at 19:36, Chris Angelico
On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann
wrote: On 1/8/21 4:31 PM, Mats Wichmann wrote:
Someone reported a testsuite break on stuff I work on (scons) with 3.10a4, and it looks similar to this which appears in the changelog at
https://docs.python.org/3.10/whatsnew/changelog.html#changelog
bpo-23898: Fix inspect.classify_class_attrs() to support attributes
with
overloaded __eq__ and __bool__. Patch by Mike Bayer.
Except when I go look at that BPO issue, it's old - closed 2015. Is this appearing in the 3.10 changelog in error? Sorry - confused !!!
okay, that was silly, I didn't realize the changelog was cumulative over many versions, so that entry was not for 3.10 at all (teach me to do searching in browser window, where it just flies right past any section headings so I miss it was for a different version :) ).
The test in question does indeed touch a class which overrides __bool_ in order to raise an exception (to say "don't do that"), and in the test run the (expected) exception is not raised.
So updated information: the test in question is checking if a class (A) has an attribute using a truth test, where the attribute's value is an instance of another class (B) and expecting that that will cause the __bool__ method to be called. [aside: this test is done to validate that a class which really doesn't want this kind of test indeed rejects it] That apparently no longer happens, if it's wrapped in a try block ??? Distilled down to simple case:
class A: pass
class B: def __bool__(self): raise AttributeError("don't do that!")
a = A() b = B() a.b = b # expect this to cause b.__bool__ to be called if a.b: print("Found it!")
and it raises the exception. But when protected:
try: if a.b: pass except AttributeError: print("Got expected exception") else: print("Missed expected exception")
it won't trigger. But if I add a "real" statement in the block following the "if", then it's back to the pre-3.10 behavior of calling __bool__:
try: if a.b: dummy = True except AttributeError: print("Got expected exception") else: print("Missed expected exception")
Any thoughts on this?
Oooh interesting. I tried on a build of 3.10 from October and: 1) The unguarded version bombed out with an exception 2) The "if... pass" version reported that it got the exception 3) The "if... dummy" version reported that it got the exception
ie every one of them did indeed raise. But on a fresh build from the master branch, I got the same results you did. That means the change happened some time between commit 497126f7ea and commit ace008c531, an 800ish commit span.
I'll start bisecting to try to track this down. It looks like "if a.b: pass" is getting partially optimized out; the disassembly shows a being loaded, its attribute b being looked up, and then it just jumps to the else - there's no POP_JUMP_IF_FALSE as there is when there's a bit of actual code in there.
ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/K2LD2L5R... Code of Conduct: http://python.org/psf/codeofconduct/