# Pattern matching on constants that aren't in a namespace (especially sentinels) **URL:** \ **Category:** Ideas\ **Created:** [June 26, 2026, 9:30am UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916 "2026-06-26T09:30:04Z")\ **Posts on this page:** 12\ **Page:** 4
**Author:** ![tstefan](https://avatars.discourse-cdn.com/v4/letter/t/f475e1/32.png) [@tstefan](https://discuss.python.org/u/tstefan)\ **Post date:** [July 6, 2026, 7:51pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/62 "2026-07-06T19:51:58Z")
> [@tmk](#): > > ### 3. `global`/`local` > > (requires `local` as a new (soft?) keyword) 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. > [@tmk](#): > > ### 5. `globals`/`locals` > > (these are currently builtins) 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** > > ```python > >>> 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") > > ``` ---
**Author:** ![Monarch](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/monarch/32/18530_2.png) [@Monarch](https://discuss.python.org/u/Monarch)\ **Post date:** [July 6, 2026, 8:20pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/63 "2026-07-06T20:20:24Z")
Changing the meaning of `case (global|globals|local|locals).` is a breaking change. A simple search on GitHub shows `case globals.ATTR` is not unheard of. ---
**Author:** ![tstefan](https://avatars.discourse-cdn.com/v4/letter/t/f475e1/32.png) [@tstefan](https://discuss.python.org/u/tstefan)\ **Post date:** [July 6, 2026, 8:51pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/64 "2026-07-06T20:51:17Z")
> [@Monarch](#): > > Changing the meaning of `case (global|globals|local|locals).` is a breaking change. No, you are conflating different things here. `case global.` is a syntax error currently, so changing it would certainly _not_ be a breaking change! Changing `case local.` would be a breaking change as I just said. Changing the grammar for `case (globals|locals).` would be a breaking change, but just allowing attribute lookup for these two builtin function would not be a breaking change. ---
**Author:** ![JoBe](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jobe/32/26961_2.png) [@JoBe](https://discuss.python.org/u/JoBe)\ **Post date:** [July 11, 2026, 1:34pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/65 "2026-07-11T13:34:16Z")
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. ---
**Author:** ![tmk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tmk/32/10935_2.png) [@tmk](https://discuss.python.org/u/tmk)\ **Post date:** [July 20, 2026, 4:51pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/66 "2026-07-20T16:51:51Z")
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: > ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [July 20, 2026, 6:36pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/67 "2026-07-20T18:36:51Z")
> [@tmk](#): > > Prefixed “==” has emerged as the main contender of the proposed syntax but it is not a close contender, Given that roughly half of respondants prefer the status quo, I think you have an uphill battle to get this accepted. ---
**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\ **Post date:** [July 21, 2026, 10:28am UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/68 "2026-07-21T10:28:04Z")
> [@Rosuav](#): > > Given that roughly half of respondants prefer the status quo, I think you have an uphill battle to get this accepted. 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) ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [July 21, 2026, 11:37am UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/69 "2026-07-21T11:37:58Z")
> [@MegaIng](#): > > > [@Rosuav](#): > > > > Given that roughly half of respondants prefer the status quo, I think you have an uphill battle to get this accepted. > > This is an obviously incorrect interpretation of the poll data. Don’t project your own opinion onto others 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. ---
**Author:** ![stoneleaf](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stoneleaf/32/88_2.png) [@stoneleaf](https://discuss.python.org/u/stoneleaf)\ **Post date:** [July 21, 2026, 2:05pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/70 "2026-07-21T14:05:09Z")
> [@tmk](#): > > I wrote a draft PEP though there is no sponsor @tmk: if you do not yet have a sponsor, I am happy to sponsor it. ---
**Author:** ![tmk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tmk/32/10935_2.png) [@tmk](https://discuss.python.org/u/tmk)\ **Post date:** [July 22, 2026, 9:47am UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/71 "2026-07-22T09:47:00Z")
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 ---
**Author:** ![cdce8p](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cdce8p/32/3575_2.png) [@cdce8p](https://discuss.python.org/u/cdce8p)\ **Post date:** [September 17, 2026, 10:32pm UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/72 "2026-09-17T22:32:10Z")
PEP 845 was published a few hours ago, you can find the discussion here: > [@PEP 845: Leading-Dot Value Patterns](https://discuss.python.org/t/pep-845-leading-dot-value-patterns/109100): > > For your consideration: [PEP 845](https://peps.python.org/pep-0845/), with the following abstract: This PEP enables the use of non-attribute names as value patterns in match statements. A name prefixed with a dot is looked up using the normal name resolution rules and compared to the match subject by equality in the same manner as existing value patterns, instead of being treated as a capture pattern. This makes it possible to match local variables and global variables defined in the same module without using a guard clause. de… ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [September 18, 2026, 1:28am UTC](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916/75 "2026-09-18T01:28:04Z")
4 posts were merged into an existing topic: [PEP 845: Leading-Dot Value Patterns](https://discuss.python.org/t/pep-845-leading-dot-value-patterns/109100/2) [Previous page](https://discuss.python.org/t/pattern-matching-on-constants-that-arent-in-a-namespace-especially-sentinels/107916.md?page=3)