Mailing List Archive

On 15/07/2020 12:37, Mohammad Foroughi via Python-Dev wrote:
> Hi, I had an idea regarding the pattern matching issue of comparing with a previous constant variable instead of assigning to a new local variable. I'm not sure if this has been brought up before but instead of using a symbol with the case statement what if we used a keyword.

Your mailer mangled your example a bit, but it's fairly clear all the
same. The problem with using a keyword is that it starts getting really
ungainly with complex patterns:

match value:
case global x:
print("value matches")
case Point(global x, y):
print("value matches x, y captured")
case Line(Point(global x1, y1), Point(x2, global y2)):
print("getting a bit hard to read here")

Probably the simplest thing to do is to use a namespace to force value
comparison.

from types import SimpleNamespace

# ... stuff ...

const = SimpleNamespace(x=x)

match value:
case const.x:
print("value matches")
case Point(const.x, y):
my_useful_struct.y = y

It's not ideal, but it's fairly clear what's going on if you choose your
names carefully. (And damn it, I've argued myself round to the position
I was trying to argue Tim out of a few weeks ago. Curses!)

--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/XVUUS4D5JMG5MWWGWPVDV6XNGR34AU6U/
Code of Conduct: http://python.org/psf/codeofconduct/

Hello,

Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit :
> Hi, I had an idea regarding the pattern matching issue of comparing with
> a previous constant variable instead of assigning to a new local
> variable. I'm not sure if this has been brought up before but instead of
> using a symbol with the case statement what if we used a keyword.
>
> [...]
>
> Other ideas for the keyword are "const" or "static" but these 2 are more
> difficult to recognise since they aren't in other parts of python but
> the "global" keyword is already implemented so it would be easy to
> understand.

What about simply "is", which is already a keyword?

AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
it would not make the grammar ambiguous (how can one check that for sure?).

match color:
case is RED:
print("red")
case is BLUE:
print("blue")
case other:
print(f"unknown color {other}")

or with Rhodri James' example:

match value:
case is x:
print("value matches")
case Point(is x, y):
print("value matches x, y captured")
case Line(Point(is x1, y1), Point(x2, is y2)):
print("wouldn't call that pretty, but not ugly either")


Cheers,
Baptiste

P.S.: granted, it could mislead some users into thinking that the
comparison is done with "is" instead of "=="; but then, patterns are
special in many ways, users will have to just learn them…
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/TZEJHFALXL4OUBDYNQ5D6PEALUYHG57I/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi Mohammad,

In addition to what Rhodri James has already well pointed out, here
are two additional thoughts on this.

At the moment, the keyword `global` is a marker to say that the
respective variable is /modified/ by a function.  Your suggestion
would invert that meaning and might therefore add more confusion than
what it would solve.

Moreover, to provide yet another alternative, you could also define
something along the lines of:
   this = sys.modules[__name__]
and then write:
   MATCH value:
       CASE this.x:
           ...
Of course, this is a bit of a hack and not that much different to
using SimpleNamespace.  But it demonstrates that any such keyword
would not really add that much power or save any keystrokes.

In the end, I can well imagine that a future version of Python might
add something like a "read and compare" marker to patten matching. 
But it is probably a good idea to start with a set of fully working
but rather minimalistic core features, and then let it grow and evolve
with time, guided by real use cases and issues that we run into.

Kind regards,
Tobias
 

> From: Baptiste Carvello <devel2020@baptiste-carvello.net>
> Subject: [Python-Dev] Re: PEP 622 constant value syntax idea
>
> What about simply "is", which is already a keyword?
>
> AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
> it would not make the grammar ambiguous (how can one check that for sure?).
>
> match color:
> case is RED:
> print("red")
> case is BLUE:
> print("blue")
> case other:
> print(f"unknown color {other}")
>
> or with Rhodri James' example:
>
> match value:
> case is x:
> print("value matches")
> case Point(is x, y):
> print("value matches x, y captured")
> case Line(Point(is x1, y1), Point(x2, is y2)):
> print("wouldn't call that pretty, but not ugly either")
>
>
> Cheers,
> Baptiste
>
> P.S.: granted, it could mislead some users into thinking that the
> comparison is done with "is" instead of "=="; but then, patterns are
> special in many ways, users will have to just learn them…

That is exactly why I think you should make the special things special and keep the familiar things as you know them.
So constants and variables like they are in other uses and matched values/patterns using a special construction/syntax.

And we don’t need the catch all case if we would have the IMHO more familiar:

match Color(…) as color:
case RED:
print(f”{color} is red")
case BLUE:
print(f”{color} is blue”)
else:
print(f"unknown color {color}”)

thus eliminating the whole ‘case <var>’ issue.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/4NTH5H6RX2KTVVJFJUF53UWESJIBCLYS/
Code of Conduct: http://python.org/psf/codeofconduct/

On 16/07/2020 08:16, Baptiste Carvello wrote:
> Hello,
>
> Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit :
>> Hi, I had an idea regarding the pattern matching issue of comparing with
>> a previous constant variable instead of assigning to a new local
>> variable. I'm not sure if this has been brought up before but instead of
>> using a symbol with the case statement what if we used a keyword.
>>
>> [...]
>>
>> Other ideas for the keyword are "const" or "static" but these 2 are more
>> difficult to recognise since they aren't in other parts of python but
>> the "global" keyword is already implemented so it would be easy to
>> understand.
> What about simply "is", which is already a keyword?
>
> AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
> it would not make the grammar ambiguous (how can one check that for sure?).
>
> match color:
> case is RED:
> print("red")
> case is BLUE:
> print("blue")
> case other:
> print(f"unknown color {other}")
>
> or with Rhodri James' example:
>
> match value:
> case is x:
> print("value matches")
> case Point(is x, y):
> print("value matches x, y captured")
> case Line(Point(is x1, y1), Point(x2, is y2)):
> print("wouldn't call that pretty, but not ugly either")
>
>
> Cheers,
> Baptiste
>
> P.S.: granted, it could mislead some users into thinking that the
> comparison is done with "is" instead of "=="; but then, patterns are
> special in many ways, users will have to just learn them…
Hm, plus ca change...  Your last paragraph inevitably suggests actually
using '==' rather than 'is'.
Which is something I suggested way back, but I was firmly asked by Guido
to "drop it".  (Which, up to now, I have.)
The specific objection he raised was that e.g. this example from the PEP
      case BinaryOp(left=Number(value=x), op=op, right=Number(value=y)):
would become
      case BinaryOp(left=Number(value===x), op===op,
right=Number(value===y)):
which is unparseable.  Although I can't see why it couldn't be written
      case BinaryOp(left=Number(value=    ==x), op=    ==op,
right=Number(value=   ==y)): # multiple spaces here for clarity
Rob Cliffe
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/TZEJHFALXL4OUBDYNQ5D6PEALUYHG57I/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/MYNRDEMBDMUXKY7OPKWMAV4ULHL7U62G/
Code of Conduct: http://python.org/psf/codeofconduct/