On 25/06/2020 16:48, Tim Peters wrote:
See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if
[Rhodri James firstname.lastname@example.org]
That's a dotted name and so is a constant value pattern - read the PEP.
Every dotted name in a pattern is looked up using normal Python name resolution rules, and the value is used for comparison by equality with the matching expression (same as for literals).
Then I am surprised, which is worse. "long.chain.of.attributes" looks like an assignment target, and I would have expected the case to have been a name pattern.
As always, I don't care whether something is obvious at first glance. I care whether something can be learned with reasonable effort, and "sticks" _after_ it's learned. There's essentially nothing truly obvious about programming.
This, from the PEP, is the entire grammar for a "name pattern'"
name_pattern: NAME !('.' | '(' | '=')
That's it. A plain name not followed by a dot, left paren, or equality sign.
While it may or may not surprise any given person at first glance, it's very simple. Put a fraction of the effort into learning it as you're willing to expend on articulating surprise, and it would already be far behind you ;-)
Well, now is the time for expressing surprise :-p
As I've said before, one of my main problems with the PEP is as you go through it, more and more special cases and surprises appear, and the consequences of earlier surprises generate more special cases and surprises. You claim not unreasonably that it's easy to remember that "_" is special in matches. Maybe you're right, but that decision has consequences spelled out later in the PEP that are less easy to remember. Another example: I had not previously thought the definition of name patterns to be surprising, but apparently they are (it just surprised me, at any rate). That consequently makes the definition of constant value patterns, which I was already iffy about, really quite surprising.
Each individual learning curve might be small, but cumulative total by the time you reach the end of the PEP is large. Simple match statements will, with adequate squinting, look recognisably like other areas of Python. Complex match statements won't. And that's a problem for anyone who wants to be able to read someone else's code.
Bear in mind I am predominantly a C programmer who uses Python from time to time for tools and glue. If I have to put in effort to learn new special-case rules in Python, that's an active discouragement; I'm frankly unlikely to bother, and more likely to write those tools and glue in C instead. I'm certainly much less likely to use someone else's tools and glue if I have to re-read the spec to remind myself what all the gotchas are.