[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
> `np` analogue is quite a stretch and far-fetched, really. I don't disagree. But `_` is a valid identifier so it shouldn't be special. The solution is incredibly simple: allow repeated identifiers just like in assignment so there is no need for a special wildcard symbol. > .. I disagree but this is philosophical discussion which I would rather not go down. > .. That's reasonable, although I would argue that a match is more like a for loop (which allows arbitrary assignment) than a function definition. I do understand your point though. However, I still think the inability to match against a constant not in a namespace is very annoying and could be overcome with some explicit syntax. It's reasonable for this syntax to only allow NAME to be bound (many places in the grammar do this, def, class, as, ...) but I haven't seen a satisfactory reason why there *shouldn't* be support for NAME constants; just reasons for why it's tricky. You (or one of the authors) argue against `.constant` as a matching syntax by saying:"..., it introduces strange-looking new syntax without making the pattern syntax any more expressive." but this is obviously false. It clearly does make the syntax more expressive, it allows one to express something naturally without needing to create an auxiliary structure (or the match syntax doesn't make the language more expressive either). Yes namespaces are a great idea but as a consenting adult I should be free to have constants that are not in a namespace. My constant may come in any number of forms that are not conducive to simply "wrapping it in a namespace", for example it may be used in other modules (so wrapping it would require external changes) or it might be a closure variable and so would require some explicit wrapping step. Further, you argue elsewhere that the we shouldn't worry about a syntax being strange because it's new so of course it's going to be different. Yet for invoke this reasoning as a way to reject solutions to the NAME constant issue. Pick one. (preferably the version that includes match syntax and some strange new syntax for explicit constants because I super want the match syntax). Caleb Donovick On Fri, Jul 31, 2020 at 12:40 AM Tobias Kohn wrote: > Hi Caleb, > > I will only answer to the second part, as the wildcard issue has > been brought up and discussed time and again, and the `np` > analogue is quite a stretch and far-fetched, really. > > One thing that stood out a bit to me as I feel to have seen it a > couple of times is the question of intuition, so I will add a few > more general thoughts to that... > > > [...] but it seems quite unintuitive to me [...] > > > [...] don't necessarily make it intuitively clear [...] > > > > Intuition (or lack thereof) has already been brought forward > as an argument a couple of times. I would just like to briefly > point out that there is no such thing as universal intuition in > the field of programming. We all have different training, > skills, preferences and experiences, which make up what > we call 'intuition'. But what is intuitive is usually something > completely different to C-programmer than to a Haskell- or > Lisp-Programmer, say. And since pattern matching is really > a new feature to be introduced to Python, a feature that can > be seen in different lights, there is no 'Python-Programmer > intuition' that would apply in this case. > > As for beginners, virtually every part of programming is > unintuitive at first. Even something innocuous-looking like > assignment is often reason for confusion because `3 + 4 = x` > would probably be more 'intuitive'. But there is good reason > with regards to the bigger picture to stick to `x = 3 + 4`. > > A Python-programmer (at any level) not familiar with pattern > matching will most likely not understand all subtlety of the > syntax---but this is alos true of features like `async` or the > `/` in parameters, say. I would argue, though, that the clear > choice of keywords allow anyone to quickly look pattern > matching up and get informed on what it does. So, we do > not need to come with something that is entirely 'intuitive' > and 'self-evident'. But by sticking to common convention > like `_` as wildcard, we can help quickly build the correct > intuition. > > > In your examples, for instance, it is perfectly obvious to me > that you cannot directly assign to attributes and it would in > fact look very weird to my eyes if you could. Your use case > is quite similar to initialisers and you are arguing that you > would like being able to write: > ``` > *class* Point: > *def* __init__(self, self.x, self.y): > *pass* > ``` > rather than the more verbose: > ``` > *class* Point: > *def* __init__(self, x, y): > self.x, self.y = x, y > ``` > I do not think that this would be a good idea for either > parameters or patterns. After all, pattern matching is > **not** assignment, even though it is related to it,
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
Your point about wanting a way to use an unqualified name as a value pattern is not unreasonable, and as you may recall we had an elegant solution in version 1 of the PEP: a leading dot. However that was booed away by the critics, and there has been no consensus (not even close) on what to do instead. Any solution that involves special markup (like bringing back the leading dot, or backticks, or a question mark, or any other sigil) can easily be added in a future version of Python. There is one solution that I personally find acceptable but which found little support from the other PEP authors. It is a rule also adopted by Scala. This is to make it so that any identifier starting with a capital letter (possibly preceded by one or more underscores) is a value pattern. I note that in Scala, too, this is different in patterns than elsewhere in the language: Scala, like Python, allows identifiers starting with a capital letter to be assigned in other contexts -- just not in patterns. It also uses roughly the same *conventions* for naming things as PEP 8 (classes Capitalized, constants UPPERCASE, variables and methods lowercase). I also note that Scala allows backticks as another way to force interpretation as a value pattern (though apparently it's not used much for this purpose). Finally I note that some human languages don't distinguish between lowercase and uppercase (IIUC the CJK languages fall in this category). I don't know what conventions users writing Python using identifiers in their native language use to distinguish between constants and variables, but I do know that they still use the Latin alphabet for keywords, builtins, standard library names, and many 3rd party library names. This is why I gave my proposed rule as "starting with a capital letter" and not as "not starting with a lowercase letter", so that `case こんにちは:` will bind the name こんにちは instead of looking up that name; these seem the more useful semantics. If a Japanese user wanted to look up that name they could write `HELLO = こんにちは` followed by `case HELLO:`. (Of course, Latin-using users can do the same thing if they have a name starting with a lowercase letter that they want to use as a value pattern.) Unfortunately we cannot leave the Capitalized rule to a future version of Python, since the PEP as written interprets `case HELLO:` as a capture pattern. (A compromise would be to disallow Capitalized identifiers altogether, leaving the door open for a decision either way in the future. But in that case I'd rather press for just instituting the rule now.) About `_` enough has been written already. On Sun, Aug 2, 2020 at 6:44 PM Caleb Donovick wrote: > > `np` analogue is quite a stretch and far-fetched, really. > > I don't disagree. But `_` is a valid identifier so it shouldn't be > special. The solution is incredibly simple: allow repeated identifiers just > like in assignment so there is no need for a special wildcard symbol. > > > .. > > I disagree but this is philosophical discussion which I would rather not > go down. > > > .. > > That's reasonable, although I would argue that a match is more like a for > loop (which allows arbitrary assignment) than a function definition. I do > understand your point though. > > However, I still think the inability to match against a constant not in a > namespace is very annoying and could be overcome with some explicit > syntax. It's reasonable for this syntax to only allow NAME to be bound > (many places in the grammar do this, def, class, as, ...) but I haven't > seen a satisfactory reason why there *shouldn't* be support for NAME > constants; just reasons for why it's tricky. > > You (or one of the authors) argue against `.constant` as a matching syntax > by saying:"..., it introduces strange-looking new syntax without making > the pattern syntax any more expressive." but this is obviously false. It > clearly does make the syntax more expressive, it allows one to express > something naturally without needing to create an auxiliary structure (or > the match syntax doesn't make the language more expressive either). Yes > namespaces are a great idea but as a consenting adult I should be free to > have constants that are not in a namespace. My constant may come in any > number of forms that are not conducive to simply "wrapping it in a > namespace", for example it may be used in other modules (so wrapping it > would require external changes) or it might be a closure variable and so > would require some explicit wrapping step. > > Further, you argue elsewhere that the we shouldn't worry about a syntax > being strange because it's new so of course it's going to be different. > Yet for invoke this reasoning as a way to reject solutions to the NAME > constant issue. Pick one. (preferably the version that includes match > syntax and some strange new syntax for explicit constants because I super > want the match syntax). > > Caleb Donovick > > On Fri, Jul 31, 2020 at 12:4
