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 

> 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 

    case mylib.STATUS_OK, ^result:

Here if I forgot the pin, I'd likely get a NameError.

Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
Message archived at 
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to