> Here, `Child` will *not* match as a sequence, even though it probably should,
Strong disagree, if I explicitly set `__match_seq__` to `False` in `Parent` I probably have a good reason for it and would absolutely expect `Child` to not match as a sequence. > - Raise at class definition time if it's set to anything other than True I feel like this is a consenting adults thing. Yeah you probably won't need to set a flag to `False` but I don't see why it should be forbidden. On Wed, Mar 31, 2021 at 3:35 PM Brandt Bucher <brandtbuc...@gmail.com> wrote: > Guido van Rossum wrote: > > On Wed, Mar 31, 2021 at 2:14 PM Brandt Bucher brandtbuc...@gmail.com > > wrote: > > > (One change from my last email: it doesn't allow `__match_map__` / > > > `__match_seq__` to be set to `False`... only `True`. This prevents some > > > otherwise tricky multiple-inheritance edge-cases present in both of our > > > flagging systems that I discovered during testing. I don't think there > are > > > actual use-cases for unsetting the flags in subclasses, but we can > revisit > > > that later if needed.) > > That's surprising to me. Just like we can have a class that inherits from > > int but isn't hashable, and make that explicit by setting `__hash__ = > > None`, why couldn't I have a class that inherits from something else that > > happens to inherit from Sequence, and say "but I don't want it to match > > like a sequence" by adding `__match_sequence__ = False`? AFAIK all Mark's > > versions would support this by setting `__match_kind__ = 0`. > > The issue isn't when *I* set `__match_seq__ = False` or > `__match_container__ = 0`. It's when *one of my parents* does it that > things become difficult. > > > Maybe you can show an example edge case where this would be undesirable? > > Good idea. I've probably been staring at this stuff for too long to figure > it out myself. :) > > As far as I can tell, these surprising cases arise because a bit flag can > only be either 0 or 1. For us, "not specified" is equivalent to 0, which > can lead to ambiguity. > > Consider this case: > > ``` > class Seq: > __match_seq__ = True > # or __match_container__ = MATCH_SEQUENCE > > class Parent: > pass > > class Child(Parent, Seq): > pass > ``` > > Okay, cool. `Child` will match as a sequence, which seems correct. But > what about this similar case? > > ``` > class Seq: > __match_seq__ = True > # or __match_container__ = MATCH_SEQUENCE > > class Parent: > __match_seq__ = False > # or __match_container__ = 0 > > class Child(Parent, Seq): > pass > ``` > > Here, `Child` will *not* match as a sequence, even though it probably > should. The only workarounds I've found (like allowing `None` to mean "this > is unset, don't inherit me if another parent sets this flag", ditching > tp_flags entirely, or not inheriting these attributes) feel a bit extreme > just to allow some users to do the moral equivalent of un-subclassing > `collections.abc.Sequence`. > > So, my current solution (seen on the branch linked in my earlier email) is: > > - Set the flag if the corresponding magic attribute is set to True in the > class definition > - Raise at class definition time if it's set to anything other than True > - Otherwise, set the flag if any of the parents set have the flag set > > As far as I can tell, this leads to the expected (and current, as of > 3.10.0a6) behavior in all cases. Plus, it doesn't break my mental model of > how inheritance works. > _______________________________________________ > 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/R3BGDN6NINJMLUWBVMVYIGORSLPJOMJP/ > 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/PRCDAGDDSJGLEVXFEPX26VB7JENYEDAF/ Code of Conduct: http://python.org/psf/codeofconduct/
