I've raised: https://bugs.python.org/issue42899.
The triggering commit was: c71581c7a4192e6ba9a79eccc583aaadab300efa bpo-42615: Delete redundant jump instructions that only bypass empty blocks (GH-23733) On Mon, Jan 11, 2021 at 8:04 PM Guido van Rossum <gu...@python.org> wrote: > All that said (I agree it's surprising that 3.10 seems backwards > incompatible here) I would personally not raise AttributeError but > TypeError in the `__bool__()` method. > > On Mon, Jan 11, 2021 at 11:51 AM Pablo Galindo Salgado < > pablog...@gmail.com> wrote: > >> 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 <ros...@gmail.com> wrote: >> >>> On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann <m...@wichmann.us> 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-le...@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/K2LD2L5RF2ZFUYEXQ3Z5U4TY5QBRFPCQ/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@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/7DMQXD3EF6CIAUIHFORMXEOUDZGUO2YW/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/VQ5FDBBCCF7FB3D2AH4J2LN6WQWJSBAJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/H2ASW6MXIJEXWJPSV4FW7CGEOVZS6JV3/ Code of Conduct: http://python.org/psf/codeofconduct/
