[Guido wrote]
>
> Also, I think that we should probably separate this out in two separate
> flag sets, one for subjects and one for class patterns -- it is pretty
> confusing to merge the flag sets into a single value when their
> applicability (subject or class pattern) is so different.
That would require two different special attributes, which adds bulk
without adding any value.
__match_kind__ = MATCH_SEQUENCE | MATCH_DEFAULT
should be clear to anyone familiar with integer flags.
The combined flags might be clearer if the class matching flags were "MATCH_CLS_DEFAULT" and "MATCH_CLS_SELF"
Without that, it isn't obvious that they're modifying the way class matching works.
Alternatively, given Guido's suggestion of two attributes, they could be "__match_container__" and "__match_class__".
The value of splitting them is that they should compose better under inheritance - the container ABCs could set "__match_container__" appropriately without affecting the way "__match_class__" is set.
An implementation might flatten them out at class definition time for optimisation reasons, but it wouldn't need to be part of the public API.
Cheers,
Nick.