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. > > Pattern matching is complimentary to the object-oriented paradigm. > > It's not until the very end of document, in the "History and Context" it > tells the whole truth: > > > With its emphasis on abstraction and encapsulation, object-oriented > > programming posed a serious challenge to pattern matching. > > You may wonder how "complimentary" and "posed a serious challenge" > relate to each other. There's no need to wonder. Just keep reading: "In short: in object-oriented programming, we can no longer view objects as tagged tuples. The arguments passed into the constructor do not necessarily specify the attributes or fields of the objects. Moreover, there is no longer a strict ordering of an object's fields and some of the fields might be private and thus inaccessible. And on top of this, the given object might actually be an instance of a subclass with slightly different structure. To address this challenge, patterns became increasingly independent of the original tuple constructors." The challenge was not, as you imply, that OOP was a challenger to pattern matching by offering an alternative idiom that made pattern matching obsolete. The challenge was to update pattern matching implementations to work with objects that don't map well to tagged tuples. [...] > As that citation suggests, the paper is not directly linked from the > PEP635. But the preprint is now accessible from the conference page, > https://conf.researchr.org/home/dls-2020?#event-overview (direct link > as of now: 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, > 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". 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. Here's a toy proposal, not intended to be taken too seriously: for local constants, inside a function, the compiler could detect and reject (with a SyntaxError) more than one attempt to bind a value to a name declared as constant, with no runtime cost. Outside of functions, we could add one extra scope between locals and globals, a "const" scope, which implements write-once semantics. This would make every global and builtin name lookup more costly. Looking at the paper, I like the look of Elixer's pin operator: case ^mylib.STATUS_OK, result: would match mylib.STATUS_OK by value, without binding, and capture result. I think that's better than the PEP's current DWIM (Do What I Mean) approach that a dotted identifier must be a constant and an undotted identifier is a capture pattern. On the other hand, I can see myself forgetting the pin and accidentally binding to (pseudo-)constants: case mylib.STATUS_OK, result: would accidentally replace the STATUS_OK code. Ouch. Maybe we should flip the meaning of pin and have it mark capture patterns? case mylib.STATUS_OK, ^result: Here if I forgot the pin, I'd likely get a NameError. -- Steve _______________________________________________ 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/FFHRMEBIXGYCWXSYH52QHD76O7MWZQDW/ Code of Conduct: http://python.org/psf/codeofconduct/
