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/
