Hello, On Sun, 15 Nov 2020 22:05:46 +1100 Steven D'Aprano <st...@pearwood.info> wrote:
> On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote: > > > Just to give one example, literally at the very beginning, at the > > "Pattern Matching and OO" section (3rd heading) it says: > > If it's the third heading, it's not *literally* at the very beginning. Thanks for stopping by that. 3rd of 26, but yeah, "beginning-ness is in the eye of beholder". [] > > You may wonder how "complimentary" and "posed a serious challenge" > > relate to each other. > > There's no need to wonder. Just keep reading: I read it in full, and explained my concerns with the wording (of PEP625 in general): is seems to be carefully chosen to lead the reader to believe that the view presented in PEP634 is the only viable choice, and to downplay other alternatives (too much, and unfairly). [] > > https://gvanrossum.github.io//docs/PyPatternMatching.pdf). > > It would be nice to have the PEP link to the paper. I found it very > useful for my understanding to compare how other languages solved or > avoiding these issues. > > > > I disagree strongly with your further points about Named Constants > and Scopes. I think you make unjustified, and mostly likely wrong, > statements like: > > > Under strict academic peer review, the paper would have been > > returned for elaboration, Well, this is not a statement, but a speculation, based on reading many complaints from (usually junior) researches of how it's hard to get a paper published/conf-accepted when a subject concern improvement to an existing technique - there're oftentimes multiple rounds of rejections with suggestions to prove the point that it's indeed "improvement" and how it compares to actual and possible alternatives. > > amount of work to implement pattern matching is certainly an order > > of magnitude larger than to introduce constants > > > The only reasons for not implementing the same solution [block > > scopes] in Python would be intertia of thought and "but it's not > > done anywhere else in Python". By these two I stand, yeah. (And ready to be proven wrong, be ashamed, and learn from it.) > but in an effort to try to keep matters focused, I won't elaborate. > > Having said that, I would like to see some discussion on what it > would take to bring in constants to the language in a fully backwards > compatible fashion, without hurting performance. Perhaps it is as > easy as you say, perhaps not. If it is easy, that might work for > pattern matching. It is isn't easy, it would be nice to know why. Thanks, that's exactly what I'd like to see too. And while it was pointed previously that this is orthogonal matter to pattern matching, the common sense keeps kicking in, suggesting that it's a *prerequisite* to having non-adhoc pattern matching design. > Here's a toy proposal, [] The baseline of my version is much simpler: # This makes "const" a kind of hard keyword for this module from __future__ import const FOO: const = 1 # obviously, this is constant Foo_Bar: const = 2 # this is too foo: const = 3 # and like it or not, but this is constant either "const" annotation is recognized by compiler (scope resolving component, aka symtable builder to be exact) as a property orthogonal to localness/globalness. Literally, "symtable" module (https://docs.python.org/3/library/symtable.html#symtable.Symbol) will grow Symbol.is_const() method. The rest should be clear - if there's: case sym: Where Symbol.is_const() is true for "sym", then value of that symbol is used for matching (instead of treating it as a binding target). This definitely would be very beginning of const's journey in Python, but exactly the amount needed to address concerns with "force enum usage" adhockery in PEP634. [] > Looking at the paper, I like the look of Elixer's pin operator: > > case ^mylib.STATUS_OK, result: And I don't. I think that "==", as used in PEP642v2, much better fits with Python syntax and overall feel (that's also what you and I suggested, before PEP642v2 picked it up, right?). But again, the whole idea to introduce const's is to drop the need for any "pin operator" in 90% of cases, when constants are used. "Pin operator" will be needed only to match against a real variable: FOO: const = 1 BAR: const = 2 i_dont_know_yet = FOO if sth() else BAR match a: case == i_dont_know_yet: print("We're better than Rust") [] > > Maybe we should flip the meaning of pin and have it mark capture > patterns? > > case mylib.STATUS_OK, ^result: But that's the humble idea, the epiphany of which I humbly spread around for a month (as an alternative to both const-introduction (we won't get around that!) or "=="-marking). Except that you used the wrong arrow - it shouldn't point away from capturing variable, but right into the heart of it: case mylib.STATUS_OK, >result: case mylib.STATUS_OK, >>result: case mylib.STATUS_OK, ->result: - all equally intuitive (aka: even if you don't get it yourself, once told, you're unlikely to forget what it means). case mylib.STATUS_OK, ^result: case mylib.STATUS_OK, ?result: case mylib.STATUS_OK, @result: - are much less so IMHO. [] > Steve -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/PSQSTOYI4PXLZMI7FD5WXVKILSK5MKQR/ Code of Conduct: http://python.org/psf/codeofconduct/
