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 <donov...@cs.stanford.edu> 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. > > > ...<INTUITION ARGUMENT>... > > I disagree but this is philosophical discussion which I would rather not > go down. > > > ...<POINT ABOUT FUNCTION PARAMETERS>... > > 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 <ko...@tobiaskohn.ch> 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, of >> course. >> >> Kind regards, >> Tobias >> >> >> >> Quoting Caleb Donovick <donov...@cs.stanford.edu>: >> >> Adding this feature would be a giant quality of life improvement for me >> and I really hope it succeeds. So I have been trying to keep up on the >> debate in this and related thread. >> >> While I do want this feature, I agree with a lot of the issues people >> are raising. >> >> First I agree that _ should not be the wildcard symbol. Or rather the >> hobgoblins in my mind think that if _ is to be the wildcard symbol it would >> be more consistent with assignment if it was bound to the last value it was >> matched with (as should other repeated identifiers) e.g., >> >> match pt: >> case (x, _, _): >> assert _ == pt[2] >> >> >> I understand the authors rationalize the decision based on conventions >> with the gettext module. I find these arguments very unconvincing. It's >> like saying the identifier np should be forbidden from appearing in cases >> because it's frequently used as the name of numpy. If there is to be a >> wildcard symbol (that does not bind and is repeatable) it should not be a >> valid identifier. >> >> Second, the distinction between a capture and constant value pattern >> should be more explicit. I don't have any great insight into the color of >> the shed beyond the numerous suggestions already made (name=, ?name, >> etc...), but it seems quite unintuitive to me that I can't capture into a >> namespace nor match a constant without a namespace. It is also unclear to >> me why it would be so terrible to add a new token or abuse an existing one. >> >> > Honestly, it doesn't help the case for `?` that it's been proposed as a >> mark for both capture patterns and value patterns (by different people, >> obviously :-). >> >> I agree that most of the proposed sheds don't necessarily make it >> intuitively clear what is a capture variable vs what is a constant. >> However they do give the programmer the ability to choose. >> >> For example if I want to modify the motivating example from the PEP >> slightly to copy attributes from one point to another I can't express it >> concisely: >> >> def update_point_3d(p: Point3d, pt): >> match pt: >> case (x, y): >> p.x, p.y = x, y >> case Point2d(x, y): >> p.x, p.y = x, y >> ... >> >> >> >> (Okay I could have just called the original make_point_3d and unpacked >> the results but it would require the creation of an unnecessary temporary.) >> >> However if the capture was explicit and any valid target could be used as >> a capture variable then I could express this cleanly: >> >> def update_point_3d(p: Point3d, pt): >> match pt: >> case (p.x=, p.y=): >> pass >> case Point2d(p.x=, p.y=): >> pass >> ... >> >> >> >> - Caleb Donovick >> >> >> >> >> >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/YEHZ4W6CLHMHZJHVO6MZYF7VSL3ZNYFU/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RQDWPDYU4ZFXHI6RJ3AGDJUHI5LGLHSV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AXVOD6B6X6FJLYSU63FZMWA4NJ4ZG5VT/ Code of Conduct: http://python.org/psf/codeofconduct/
