Pattern matching on constants that aren't in a namespace (especially sentinels)

Ideas
62

This is actually a breaking change since a soft keyword can only be introduced safely in a situation, where a name cannot appear (like in type foo=bar, where it impossible to have two names left of the assignment). Since it is possible to have a class local, it is easily possible that case local.foo has already a meaning.

That is an interesting option and would not even require any changes to the syntax. It would be sufficient if globals and locals would provide a __getattr__ function.

Emulation of a __getattr__ member for globals 
>>> import builtins
>>> class _Globals:
...     def __call__(self):
...         return builtins.globals()
...     def __getattr__(self, name):
...         return globals()[name]
...         
>>> globals = _Globals()
>>> 
>>> x = 9
>>> globals.x
9
>>> y = 10
>>> match 10:
...     case globals.x:
...         print("Matched x")
...     case globals.y:
...         print("Matched y")
1 Like
63

Changing the meaning of case (global|globals|local|locals).<ATTR> is a breaking change. A simple search on GitHub shows case globals.ATTR is not unheard of.

2 Likes
64

No, you are conflating different things here. case global.<ATTR> is a syntax error currently, so changing it would certainly not be a breaking change! Changing case local.<ATTR> would be a breaking change as I just said. Changing the grammar for case (globals|locals).<ATTR> would be a breaking change, but just allowing attribute lookup for these two builtin function would not be a breaking change.

2 Likes
65

Not only that, it should be considered bad practice to overwrite built-in names anyways, so globals = ... should work in user code, but should be avoided too.

66

The poll ran for 9 days. No big surprises fortunately or unfortunately, depending on your perspective.

Prefixed “==” has emerged as the main contender of the proposed syntax but it is not a close contender, if we go by the poll (which of course will have all sorts of statistical biases but it’s the best we’ve got here).

I wrote a draft PEP though there is no sponsor:

4 Likes
67

Given that roughly half of respondants prefer the status quo, I think you have an uphill battle to get this accepted.

68

This is an obviously incorrect interpretation of the poll data. Don’t project your own opinion onto others

3/4 of respondents like the leading dot. 1/2 like the status quo. Quite a few people have voted for both leading dot and status quo. This isn’t ranked choice, you cannot make claims about what respondents prefer. (except for yourself ofcourse)

5 Likes
69

I’m sorry, I clearly misinterpreted the data, based on the fact that (a) roughly half of people did, in fact, say that they were entirely happy with the status quo, and (b) I haven’t seen any core devs say anything about being willing to sponsor this.

I stand by my statement that it’s an uphill battle to get this accepted.

70

@tmk: if you do not yet have a sponsor, I am happy to sponsor it.

14 Likes
71

Thank you! I’ll gladly accept. I’ll look over the draft again and then open a PR on the PEP repo where people can leave comments on the text.

EDIT: and then there’ll also be a PEP discussion thread of course, where the wider community can weigh in

2 Likes
72

PEP 845 was published a few hours ago, you can find the discussion here:

3 Likes
75

4 posts were merged into an existing topic: PEP 845: Leading-Dot Value Patterns