26 ms·

yeah, I would also expect the linters to catch this. has some way to allow use of non-dotted constants been considered? something like window.global_variable in

yeah, I would also expect the linters to catch this. has some way to allow use of non-dotted constants been considered? something like window.global_variable in JavaScript? Or would I need to do something like this:? NOT_FOUND = 404 m = {"NOT_FOUND": NOT_FOUND} match value: case m["NOT_FOUND"]: pass

TrianguloY 6y ago
I may be wrong, but after reading the grammar I think your example is a syntax error. You can't access an element! A pattern syntax is completely different to a normal expression, and there is apparently no array access.
- mvolfik 6y ago
  hmm, so I would need to use some namespace class https://docs.python.org/3.8/library/types.html#types.SimpleNamespace https://docs.python.org/3.8/library/types.html#types.SimpleN...
chriswarbo 6y ago
You can do NOT_FOUND = 404 match value: case v if v == NOT_FOUND: pass On its own this is a convoluted alternative to `if`, but it can be useful when we have lots of patterns. Alternatively, we can avoid using a separate `v` variable and just use `value` directly: NOT_FOUND = 404 match value: case _ if value == NOT_FOUND: pass We can even match on a trivial value, and do all of the interesting checks using guards: NOT_FOUND = 404 match None: case _ if value == NOT_FOUND: pass This latter form acts like Lisp's `cond`, and I've used it a few times in Scala, e.g. () match { case _ if foo > bar => ... case _ if foo < bar => ... case _ if foo == bar => ... }
- hyperbovine 6y ago
  But all of these alternatives are strictly less intuitive than the original expression. A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python. This latest PEP, coming on the heels of several others like it, shows how alarmingly far from the ideal we’ve come since 2.7.
  - pansa2 6y ago
    > A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python. Yes! For the first 2 decades of its life, people loved Python because it was like “executable pseudocode”. Unfortunately over the last 5-10 years it seems to have given up on that idea, instead becoming more and more like “whitespace-sensitive C++”.
  - chriswarbo 6y ago
    > But all of these alternatives are strictly less intuitive than the original expression. I agree; I was just trying to show how pattern guards work. I would only resort to pattern guards if I need a `cond` (like my last example), or on a few cases of a more 'natural' pattern match, e.g. match foo(): case OK(msg): return success(msg) case NotFound(_) if isQuery: return success("No results matched query") case NotFound(msg): return failure(msg) ... If I were to implement your original example (i.e. 'which of these constants do I have?'), I'd probably still go with a "dictionary dispatch" (especially since it's an expression, so it works in lambdas, etc.): return { NOT_FOUND: default, OK: response, }[getCode()]()

TrianguloY 6y ago

I may be wrong, but after reading the grammar I think your example is a syntax error. You can't access an element! A pattern syntax is completely different to a normal expression, and there is apparently no array access.

mvolfik 6y ago
hmm, so I would need to use some namespace class https://docs.python.org/3.8/library/types.html#types.SimpleNamespace https://docs.python.org/3.8/library/types.html#types.SimpleN...

chriswarbo 6y ago

You can do NOT_FOUND = 404 match value: case v if v == NOT_FOUND: pass On its own this is a convoluted alternative to `if`, but it can be useful when we have lots of patterns. Alternatively, we can avoid using a separate `v` variable and just use `value` directly: NOT_FOUND = 404 match value: case _ if value == NOT_FOUND: pass We can even match on a trivial value, and do all of the interesting checks using guards: NOT_FOUND = 404 match None: case _ if value == NOT_FOUND: pass This latter form acts like Lisp's `cond`, and I've used it a few times in Scala, e.g. () match { case _ if foo > bar => ... case _ if foo < bar => ... case _ if foo == bar => ... }

hyperbovine 6y ago
But all of these alternatives are strictly less intuitive than the original expression. A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python. This latest PEP, coming on the heels of several others like it, shows how alarmingly far from the ideal we’ve come since 2.7.
- pansa2 6y ago
  > A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python. Yes! For the first 2 decades of its life, people loved Python because it was like “executable pseudocode”. Unfortunately over the last 5-10 years it seems to have given up on that idea, instead becoming more and more like “whitespace-sensitive C++”.
- chriswarbo 6y ago
  > But all of these alternatives are strictly less intuitive than the original expression. I agree; I was just trying to show how pattern guards work. I would only resort to pattern guards if I need a `cond` (like my last example), or on a few cases of a more 'natural' pattern match, e.g. match foo(): case OK(msg): return success(msg) case NotFound(_) if isQuery: return success("No results matched query") case NotFound(msg): return failure(msg) ... If I were to implement your original example (i.e. 'which of these constants do I have?'), I'd probably still go with a "dictionary dispatch" (especially since it's an expression, so it works in lambdas, etc.): return { NOT_FOUND: default, OK: response, }[getCode()]()