Allow _ Loads?

[brandtbucher]

This is a bit pathological, but should we allow loading the name _ in patterns? I think we should say "no", since it really has no place outside of obfuscated code and masks the special meaning of _:

match _:  # This is fine, we don't do anything special here.
    case ._:  ...  # I think we should raise.
    case _() | ._():  ...  # I think we should raise.
    case _.x | _.x(): ...  # Probably okay? Sort of looks like a "hasattr" check.
    case x._ | x._(): ...  # Probably okay? Sort of looks like it matches any attr.

[gvanrossum]

yes, make it so

[brandtbucher]

Great. Do we have a resolution on attribute access (the last two cases in the example)?

[gvanrossum]

_.x should raise like all the others.

X._ is none of our business.

[Tobias-Kohn]

case _.x | _.x(): ... # Probably okay? Sort of looks like a "hasattr" check.

Actually, that it looks like a hasattr check is a great reason why we should raise in this case. Dotted names are constants (i.e. using load semantics). Accordingly, _.x does not check if the object to match has an attribute x, but looks up the object _.x.

Personally, I am not happy about allowing x._ because _ has a special meaning in pattern matchng, but I can understand why you want to keep it. Nonetheless, it should be briefly discussed in the PEP. I will add that.

[gvanrossum]

Personally, I am not happy about allowing x._ because _ has a special meaning in pattern matching, but I can understand why you want to keep it.

I also find it is ugly, but until we make _ a reserved word (like False) we cannot exclude in this case. The special meaning of _ in pattern matching always happens when _ would be stored in the current namespace. It makes sense then to forbid lookups of _ in the current namespace. But we don't own other namespaces.

It would be different if our wildcard character were something else (e.g. *) since that is not syntactically a NAME.

I don't know what a user would be expecting who wrote case x._ thinking that _ meant "wildcard" here. "If it is equal to any attribute of x" ??? Ditto for case x._() -- "if it is an instance of any class in x" ??? Those users who are so confused that they believe this has a meaning related to wildcards will not be very successful. Fortunately the error message that comes from this is very clear:

>>> import sys
>>> match 42:
...   case sys._: print("Heh")
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AttributeError: module 'sys' has no attribute '_'
>>> 

Finally, making _ a soft keyword would not help, because of the very meaning of "soft keywords". :-)

[Tobias-Kohn]

I also find it is ugly, but until we make _ a reserved word (like False) we cannot exclude in this case. The special meaning of _ in pattern matching always happens when _ would be stored in the current namespace. It makes sense then to forbid lookups of _ in the current namespace. But we don't own other namespaces.

Yes, that convinced me.

[gvanrossum]

There was a fair amount of pushback on this on python-dev. Honestly nothing much would be lost if we allowed ._ and _.blah.

[brandtbucher]

Agreed. And we don't need to do anything, since I never actually got around to raising there. 🤷‍♂️

[Tobias-Kohn]

On second thought, allowing ._ and _.blah feels slighly more consistent with the rule that dotted names have load semantics, anyway.

[gvanrossum]

Okay, let’s remove this restriction.

[gvanrossum]

I've committed the change to the PEP: python/peps@410ba6d