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
Message archived at 
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to