[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Baptiste Carvello]

Hi,

Le 23/11/2020 à 01:41, Greg Ewing a écrit :
> On 23/11/20 7:49 am, Daniel Moisset wrote:
>> Look at the following (non-pattern-matching) snippet:
>>
>>     event = datetime.date(x, month=y, day=z)
> 
> The only names that are treated as lvalues there are to the left
> of an '='. […]
This is a crucial point for me as well. Especially "month=y" meaning
assign from month to y in "case datetime.date(x, month=y, day=z)" still
feels really weird, even after reading it times and again in this
many-month-old discussion. Sure, people who use pattern matching daily
will get used to it, but what about those who only use it once in a while?

I say this as someone who fully appreciates the parallelism between a
pattern and the corresponding constructor, and the elegance of this
design choice. The rational me likes it, but the instinctive me can't
get comfortable with its consequences ;-)

If it can be done, replacing the "=" sign with "as" feels like a good
compromise: the parallelism is still there, with just enough difference
to stand out.

Cheers,
Baptiste
___
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/P2OIXVBAPR7RDBJJA4DZICO3ZAJYP53E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Brian Coleman]

Greg Ewing wrote:
> On 23/11/20 7:49 am, Daniel Moisset wrote:
> > Look at the following (non-pattern-matching)
> > snippet:
> > event = datetime.date(x, month=y, day=z)
> > 
> > The only names that are treated as lvalues there are to the left
> of an '='. The rules are a lot simpler.
> One of the Zen lines says "If it's hard to explain, it's probably
> a bad idea." I think the proposed rules for match cases are
> objectively harder to explain than those for other expressions,
> because they're more complicated.

I don't believe that it is correct that `month` in `month=y` and `day` in 
`day=z` in the expression `event = datetime.date(x, month=y, day=z)` are 
lvalues. They are definitely not assignment targets in the same sense that 
`event` is an assignment target. `month` and `day` are used to bind the 
arguments `y` and `z` to the `month` and `day` arguments accepted by the `date` 
constructor. `event` can be accessed and rebound in the scope that invokes 
`datetime.date`. However, `month` and `day` are only bound to `y` and `z` in 
the scope of the body of the `datetime.date` constructor and are not accessible 
in the scope that invokes `datetime.date`. The behaviour is significantly 
different.
___
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/FDEVMYO3YCFZO3UYTP7D2G3HHKFP7EXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 23/11/20 7:49 am, Daniel Moisset wrote:

Look at the following (non-pattern-matching) snippet:

event = datetime.date(x, month=y, day=z)


The only names that are treated as lvalues there are to the left
of an '='. The rules are a lot simpler.

One of the Zen lines says "If it's hard to explain, it's probably
a bad idea." I think the proposed rules for match cases are
objectively harder to explain than those for other expressions,
because they're more complicated.

--
Greg
___
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/AVXFD6J2LGGTJH5LZKBJ3EAGUPV6QPGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Daniel Moisset]

On Sun, 22 Nov 2020 at 00:31, Greg Ewing 
wrote:

> On 22/11/20 6:47 am, David Mertz wrote:
> > I'm convinced by Guido,
> > Brandt, and others that the binding  use will be far more common, so
> > adding extra characters for the 90% case does not feel desirable
>
> Minimising the number of characters is not the only consideration.
> Readability counts too, and I think the proposed DWIM rules suffer
> in the readability area.
>
> There are about five different contexts in which a bare name can
> appear as part of a match case:
>
> * As a constructor name
> * As a bare name in an argument position
> * As part of a dotted expression
> * On the left of an =
> * On the right of an =
>
> Only in some of those contexts is it treated as a name to be
> assigned. That's a fairly complex bit of mental parsing to do
> when reading a case.
>
>
Hi Greg,

Look at the following (non-pattern-matching) snippet:

event = datetime.date(x, month=y, day=z)


you have bare names appearing as:
* a constructor name (date)
* bare name in an argument position (x)
* part of a dotted expression (datetime, date)
* left of = (event, month, day)
* right of = (y, z)

some of them are lookups in the namespace (datetime, x, y, z). Others are
targets to write (event). "date" is actually a literal to be used as
attribute lookup, for reading (a key in the module dictionary). "month" and
"day" are literals to lookup in the list of formal parameters of a
function, for writing into the new function stack frame.

I never found Python students struggle too much with the line above, and I
don't expect it to be much different for names in patterns. Names in Python
can appear with a lot of different "roles" in a lot of different contexts,
but the context is usually easy to recognise (is it left or right of a
chain of dots? does it have an = on the left or right? is it in an argument
list? a parameter list?).

Of course I can never deny if you tell me "I find this syntax hard to read"
(only a person can decide what's easy or hard to read for them), but I
don't think this "bare names appear in many contexts" is a solid
explanation.

A hypothesis I have is that many readers of the PEP have been scared of
these semantics because they have been laid bare when explaining them in
detail, but would never notice in day to day life, in the same way that
most Python users would never stop twice to look at the meaning of "a.b.c =
0", even if a semantic description requires us to describe that each of the
three names has a different role ("a" is a lookup in the current scopes,
"b" is a constant name for the purpose of reading attributes, and "c" is a
constant name for the purpose of writing attributes). But looking at the
details description of what's going on under the hood is scarier than the
intuitive look, and when people read the PEP they are looking under the
hood rather than looking at this as users. This is guesswork and could be
absolutely wrong, but I hope it helps read this with a different set of
eyes.



> --
> Greg
> ___
> 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/LMALNSPBLL3MHFOJHBGGO24IDS6CI5R3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/6VKTXLNWA6ZAXS6TQRT6Z3HS7F2OQLIL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Marco Sulla]

On Sun, 22 Nov 2020 at 01:27, Greg Ewing  wrote:
> That's a fairly complex bit of mental parsing to do
> when reading a case.

I agree, that's why I wrote pattern matching seems exotical to me. I
was accustomed by Python to read the code as if it's wrote in simple
English. I must admit this is not entirely true for more complex
features (generators, async etc), but I feel pattern matching
particularly less readable. So any effort to make it more readable is
good IMHO. My two cents of a simple programmer.

On Sun, 22 Nov 2020 at 01:43, Greg Ewing  wrote:
>
> On 22/11/20 1:07 pm, Henk-Jaap Wagenaar wrote:
> > On Sat, 21 Nov 2020 at 19:58, Glenn Linderman  > > wrote:
> >
> > Don't () already indicate an expression to be evaluated?
> >
> > Does it?
> >
> > [(a, b)] = [(0, 1)]
>
> Presumably a comma would be needed to match a 1-tuple.
>
> case (x): # matches the value of x
>
> case (x,): # matches any 1-tuple and binds x

I think it could potentially be confused with a programmer style.
Parenthesis are optional for tuples. Someone could think it could also
write
case x:
to match the value of x, but actually it binds to x and it will be
hard to debug.
___
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/4B3XUSEZGCYCQMOFCGRQ3H76MT3GGTJ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 22/11/20 1:07 pm, Henk-Jaap Wagenaar wrote:
On Sat, 21 Nov 2020 at 19:58, Glenn Linderman > wrote:


Don't () already indicate an expression to be evaluated?

Does it?

[(a, b)] = [(0, 1)]


Presumably a comma would be needed to match a 1-tuple.

   case (x): # matches the value of x

   case (x,): # matches any 1-tuple and binds x

--
Greg
___
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/4T3OFJEIGMZEW5QJ3WXFAICK6LZD3P5Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 22/11/20 6:47 am, David Mertz wrote:
I'm convinced by Guido, 
Brandt, and others that the binding  use will be far more common, so 
adding extra characters for the 90% case does not feel desirable


Minimising the number of characters is not the only consideration.
Readability counts too, and I think the proposed DWIM rules suffer
in the readability area.

There are about five different contexts in which a bare name can
appear as part of a match case:

* As a constructor name
* As a bare name in an argument position
* As part of a dotted expression
* On the left of an =
* On the right of an =

Only in some of those contexts is it treated as a name to be
assigned. That's a fairly complex bit of mental parsing to do
when reading a case.

--
Greg
___
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/LMALNSPBLL3MHFOJHBGGO24IDS6CI5R3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Henk-Jaap Wagenaar]

On Sat, 21 Nov 2020 at 19:58, Glenn Linderman  wrote:

> Don't () already indicate an expression to be evaluated?
>

Does it?

[(a, b)] = [(0, 1)]
print(a)

gives 0 as output.
___
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/2HUHO5RB3UKNCHVVX6AAY6ZS25DSNCTL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Marco Sulla]

On Sat, 21 Nov 2020 at 18:52, David Mertz  wrote:
> So in my mind, if I had the choice, it is a decision between a sigil and a 
> word
> to indicate "no, really use this name as a value!" I like a word better, but 
> none
> of the current keywords really make sense, so it would need to be a new word.
> I suggested "value", but another word might be better.

What about `equals`?
___
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/PFQJN4QY33QUQVSNOB55VTMLNHJZBCWN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Glenn Linderman]

On 11/21/2020 9:47 AM, David Mertz wrote:
So in my mind, if I had the choice, it is a decision between a sigil 
and a word to indicate "no, really use this name as a value!" I like a 
word better, but none of the current keywords really make sense, so it 
would need to be a new word. I suggested "value", but another word 
might be better.


NOT_FOUND = 404
match var:
    case 200:
    print("OK")
    case (NOT_FOUND):
    print("Not Found")
    case other_code:
    print("Other code", other_code )

Don't () already indicate an expression to be evaluated?

It's only one character longer than the early . suggestion, and already 
has the desired meaning of "calculated value" not "bound variable".

___
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/EQ2DSQ3Y4FBZQGW36NKCAAABOUSPZVWH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[David Mertz]

On Sat, Nov 21, 2020 at 2:47 PM Guido van Rossum  wrote:

> On Sat, Nov 21, 2020 at 9:52 AM David Mertz  wrote:
>
>> So in my mind, if I had the choice, it is a decision between a sigil and
>> a word to indicate "no, really use this name as a value!" I like a word
>> better, but none of the current keywords really make sense, so it would
>> need to be a new word. I suggested "value", but another word might be
>> better.
>>
>
> The good news here is that the PEP 634 syntax is sufficiently restricted
> that we can always add this later, regardless of whether we end up wanting
> a sigil or a (soft) keyword, as long as we agree that the meaning of a bare
> name should be a capture variable.
>

I thought of that.  An incremental approach of accepting PEP 634, but
(perhaps) adding a soft keyword later is probably the most sensible thing.

If the "need the value of a plain name" is a 1% case, a workaround like
putting it into an attribute of some object before matching is a minor
issue.  If that's the 25%+ case, after experience, the argument for some
annotation of "use the value" could be added later.


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/Q7NUDCGLH2OCRK5XJ5QEEOIZ4FECKPGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Guido van Rossum]

On Sat, Nov 21, 2020 at 9:52 AM David Mertz  wrote:

> So in my mind, if I had the choice, it is a decision between a sigil and a
> word to indicate "no, really use this name as a value!" I like a word
> better, but none of the current keywords really make sense, so it would
> need to be a new word. I suggested "value", but another word might be
> better.
>

The good news here is that the PEP 634 syntax is sufficiently restricted
that we can always add this later, regardless of whether we end up wanting
a sigil or a (soft) keyword, as long as we agree that the meaning of a bare
name should be a capture variable.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/2ZME3J6XZYHCAYEKFC6OJ7LKA7TFRI7P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[David Mertz]

I'm not sure it matters in all the threads.  But my underlying opinion is
that we SHOULD have a mechanism to use a plain name (that has an assigned
value in the scope) as a value in match patterns, not only as binding
targets.

However, in contrast to Nick Coghlan, I do not think access should be the
default, but that binding should be.  I'm convinced by Guido, Brandt, and
others that the binding  use will be far more common, so adding extra
characters for the 90% case does not feel desirable, even if it is arguably
more consistent with other elements of the language.

The second example I give of binding requiring the extra syntax was for
completeness, but I would not support it myself.  If binding were to
require extra syntax, I think Nick's 'as' suggestion is better than my
prefix word idea (if only because it doesn't need a new soft keyword).  I
do not think the answer of "put the plain name into an enumeration or other
object so it can be accessed as a dotted name" is quite enough.  Yes,
that's possible, but it feels more forced.

So in my mind, if I had the choice, it is a decision between a sigil and a
word to indicate "no, really use this name as a value!" I like a word
better, but none of the current keywords really make sense, so it would
need to be a new word. I suggested "value", but another word might be
better.

On Thu, Nov 12, 2020 at 7:38 PM David Mertz  wrote:

> One idea that I cannot recall seeing, but that seems to make sense to me
> and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special symbol
> prefixing or suffixing a name, either to indicate it is or is not a binding
> target.  Of course, whether the extra word would be used for binding or for
> NOT binding is a question still.
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case value NOT_FOUND:  # use the variable value
> print("Document not found")
> case OTHER_CODE:  # bind this name
> print("Other HTTP code", OTHER_CODE)
>
> Of course, this would require a soft keyword, which is a disadvantage.
> Going the other direction:
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case NOT_FOUND:  # use the variable value
> print("Document not found")
> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")
>
> To me these read better than the punctuation characters.  But I guess some
> folks have suggested enlisting 'as', which is a word, of course.
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/WAGBJUKGS5V7AGUYDWNZAI5NNA76MXYN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Alan G. Isaac]

In Mathematica, you might do this as (roughly):

rules = {
  {x_, y_, z_} :> {x, y, z},
  {x_, y_} :> {x, y, 0.0},
  x_ :> {x, 0.0, 0.0}
  }
process[Replace[obj, rules]]

Whatever you think of the particular syntax:
The ability to declare resuable rules seems good.
Thinking of replacement functionally seems good.

fwiw, Alan Isaac


On 11/17/2020 5:02 AM, Steven D'Aprano wrote:

On Tue, Nov 17, 2020 at 08:49:28AM +0100, Marco Sulla wrote:


PS: pattern matching, for a mere mortal like me, seems to be something very
exotical.


Have you ever written code that looks like this?


 if isinstance(obj, tuple) and len(obj) ==3:
 x, y, z = obj
 elif isinstance(obj, tuple) and len(obj) == 2:
 x, y = obj
 z = 0.0
 elif isinstance(obj, float):
 x = obj
 y = z = 0.0
 else:
 raise ValueError
 process(x, y, z)


That's pattern matching.

 match obj:
 case x, y, z:
 pass
 case x, y:
 z = 0.0
 case x if isinstance(x, float):
 y = z = 0.0
 case _:
 raise ValueError
 process(x, y, z)


There may be cleaner or alternative ways to write this as a match
statement, I'm still learning pattern matching idioms myself. But in a
nutshell, they simplify what would otherwise look like a long,
repetitive chain of if, isinstance, sequence unpacking, etc.



___
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/JXTVH6JGCJMFSV66NQJ4EWGHWEZRMH5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Steven D'Aprano]

On Tue, Nov 17, 2020 at 08:49:28AM +0100, Marco Sulla wrote:

> PS: pattern matching, for a mere mortal like me, seems to be something very
> exotical.

Have you ever written code that looks like this?


if isinstance(obj, tuple) and len(obj) ==3:
x, y, z = obj
elif isinstance(obj, tuple) and len(obj) == 2:
x, y = obj
z = 0.0
elif isinstance(obj, float):
x = obj
y = z = 0.0
else:
raise ValueError
process(x, y, z)


That's pattern matching.

match obj:
case x, y, z:
pass
case x, y:
z = 0.0
case x if isinstance(x, float):
y = z = 0.0
case _:
raise ValueError
process(x, y, z)


There may be cleaner or alternative ways to write this as a match 
statement, I'm still learning pattern matching idioms myself. But in a 
nutshell, they simplify what would otherwise look like a long, 
repetitive chain of if, isinstance, sequence unpacking, etc.


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

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Marco Sulla]

On Tue, 17 Nov 2020 at 03:52, Steven D'Aprano  wrote:

> Here is a more representative example, borrowed from here:
>
> https://gvanrossum.github.io//docs/PyPatternMatching.pdf
>
>
> match node:
> case BinOp(Num(left), '+', Num(right)):
> return Num(left + right)
> case BinOp(left, '+' | '-', Num(0)):
> return simplify(left)
> case UnaryOp('-', UnaryOp('-', item)):
> return simplify(item)
> case _:
> return node
>
>
> which becomes this with the "as" proposal:
>
>
> match node:
> case BinOp(Num(as left), '+', Num(as right)):
> return Num(left + right)
> case BinOp(as left, '+' | '-', Num(0)):
> return simplify(left)
> case UnaryOp('-', UnaryOp('-', as item)):
> return simplify(item)
> case _:
> return node
>

Well, I like the idea to have a keyword instead of a sigil, but `as` does
not sounds good in English IMO. For example, in the `with` statement, it's

with x as y:
[code]

I see the pattern matching code and I ask myself: where is the x?

PS: pattern matching, for a mere mortal like me, seems to be something very
exotical. That's why an explicit, even if verbose, additional keyword seems
to me better for reading and understanding the code. For my eyes, it's the
same difference between

x = y ? z : w
and
x = y if z else w
___
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/6HPPFZNEEAWVPHC5XRA7TVPXKASF7AXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Steven D'Aprano]

On Sat, Nov 14, 2020 at 11:11:37PM +1000, Nick Coghlan wrote:
> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
> >
> > I have read a great deal of discussion on the pattern matching PEPs and 
> > less formal discussions.  It is possible I have overlooked some post in all 
> > of that, of course.
> >
> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose applies 
> > to this too :-).
> >
> > One idea that I cannot recall seeing, but that seems to make sense to me 
> > and fit with Python's feel is using a WORD to distinguish between a 
> > variable value and a binding target.  That is, instead of a special symbol 
> > prefixing or suffixing a name, either to indicate it is or is not a binding 
> > target.  Of course, whether the extra word would be used for binding or for 
> > NOT binding is a question still.
> 
> If someone was prepared to pursue this to the level of writing a 3rd
> competing PEP, the variant I would personally like to see written up
> is the one where capture patterns are all prefixed with the keyword
> `as`.
> 
> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
> match patterns with a capture pattern, and I'm going to be amending
> PEP 642 to propose using `as` when embedding capture patterns inside
> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
> From there, it's an entirely plausible step to also require the `as`
> prefix on capture patterns in sequence patterns and as top level
> standalone patterns.
> 
> I personally don't think that extra step would be a good idea due to
> the inconsistency with name binding and iterable unpacking in regular
> assignment statements (if I liked the idea, I'd have already included
> it in PEP 642), but I think "anchor match patterns in normal
> expressions rather than assignment target syntax" is a credible enough
> idea that the overall design process would benefit from having a
> champion write it up.
> 
> > To me these read better than the punctuation characters.  But I guess some 
> > folks have suggested enlisting 'as', which is a word, of course.
> 
> Indeed, and one that doesn't look too bad for top level patterns:
> 
> NOT_FOUND = 404
> match http_code:
>   case 200:
>   print("OK document")
>   case NOT_FOUND:  # use the variable value
>   print("Document not found")
>   case as other_code:  # bind this name
>   print("Other HTTP code")

It doesn't look too bad because it looks like a switch statement, with 
only one lonely capture pattern, and an especially simple one at that. 
(The bound name isn't even used, which strongly suggests that it should 
be written as the wildcard pattern.)

Here is a more representative example, borrowed from here:

https://gvanrossum.github.io//docs/PyPatternMatching.pdf


match node:
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', item)):
return simplify(item)
case _:
return node


which becomes this with the "as" proposal:


match node:
case BinOp(Num(as left), '+', Num(as right)):
return Num(left + right)
case BinOp(as left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', as item)):
return simplify(item)
case _:
return node


Here's another example from the same paper:


def create_rectangle(*args, **kwargs):
match (args, kwargs):
case ([x1, y1, x2, y2], {}) if x2-x1 == y2-y1:
return Square(x1, y1, x2-x1)
case ([x1, y1, x2, y2], {}):
return Rect(x1, y1, x2, y2)
case ([(x1, y1), (x2, y2)], {}):
return Rect(x1, y1, x2, y2)
case ([x, y], {'width': wd, 'height': ht}):
return Rect(x, y, x+wd, y+ht)


which would become:


def create_rectangle(*args, **kwargs):
match (args, kwargs):
case ([as x1, as y1, as x2, as y2], {}) if x2-x1 == y2-y1:
return Square(x1, y1, x2-x1)
case ([as x1, as y1, as x2, as y2], {}):
return Rect(x1, y1, x2, y2)
case ([(as x1, as y1), (as x2, as y2)], {}):
return Rect(x1, y1, x2, y2)
case ([as x, as y], {'width': as wd, 'height': as ht}):
return Rect(x, y, x+wd, y+ht)



-- 
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/25NAC56DIYID5L7XGMVQDM2RM6Z5FSNQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Christian Nielsen]

I very much second this opinion

/Christian


On Sat, 14 Nov 2020, 15.16 Joao S. O. Bueno,  wrote:

>
>
> On Sat, 14 Nov 2020 at 10:16, Nick Coghlan  wrote:
>
>> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
>> >
>> > I have read a great deal of discussion on the pattern matching PEPs and
>> less formal discussions.  It is possible I have overlooked some post in all
>> of that, of course.
>> >
>> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
>> applies to this too :-).
>> >
>> > One idea that I cannot recall seeing, but that seems to make sense to
>> me and fit with Python's feel is using a WORD to distinguish between a
>> variable value and a binding target.  That is, instead of a special symbol
>> prefixing or suffixing a name, either to indicate it is or is not a binding
>> target.  Of course, whether the extra word would be used for binding or for
>> NOT binding is a question still.
>>
>> If someone was prepared to pursue this to the level of writing a 3rd
>> competing PEP, the variant I would personally like to see written up
>> is the one where capture patterns are all prefixed with the keyword
>> `as`.
>>
>> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
>> match patterns with a capture pattern, and I'm going to be amending
>> PEP 642 to propose using `as` when embedding capture patterns inside
>> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
>> From there, it's an entirely plausible step to also require the `as`
>> prefix on capture patterns in sequence patterns and as top level
>> standalone patterns.
>>
>> I personally don't think that extra step would be a good idea due to
>> the inconsistency with name binding and iterable unpacking in regular
>> assignment statements (if I liked the idea, I'd have already included
>> it in PEP 642), but I think "anchor match patterns in normal
>> expressions rather than assignment target syntax" is a credible enough
>> idea that the overall design process would benefit from having a
>> champion write it up.
>>
>> > To me these read better than the punctuation characters.  But I guess
>> some folks have suggested enlisting 'as', which is a word, of course.
>>
>> Indeed, and one that doesn't look too bad for top level patterns:
>>
>> NOT_FOUND = 404
>> match http_code:
>>   case 200:
>>   print("OK document")
>>   case NOT_FOUND:  # use the variable value
>>   print("Document not found")
>>   case as other_code:  # bind this name
>>   print("Other HTTP code")
>>
>> It starts to look a bit more strange when matching sequences, though:
>>
>> match seq:
>> case as first, *middle, as last:
>> ... # Or should that be "*as middle"?
>>
>
> Although the spacing there should probably remain optional, I think
> that "* as middle" is very straightforward and easy to read.
>
>
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>> ___
>> 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/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/GFVLLQVHN2QWNX6LWHESBGRMXHLF3Z74/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/7NFU33AMGMPJDZDODMPN5VUL64RUDUW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Joao S. O. Bueno]

On Sat, 14 Nov 2020 at 10:16, Nick Coghlan  wrote:

> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
> >
> > I have read a great deal of discussion on the pattern matching PEPs and
> less formal discussions.  It is possible I have overlooked some post in all
> of that, of course.
> >
> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
> applies to this too :-).
> >
> > One idea that I cannot recall seeing, but that seems to make sense to me
> and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special symbol
> prefixing or suffixing a name, either to indicate it is or is not a binding
> target.  Of course, whether the extra word would be used for binding or for
> NOT binding is a question still.
>
> If someone was prepared to pursue this to the level of writing a 3rd
> competing PEP, the variant I would personally like to see written up
> is the one where capture patterns are all prefixed with the keyword
> `as`.
>
> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
> match patterns with a capture pattern, and I'm going to be amending
> PEP 642 to propose using `as` when embedding capture patterns inside
> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
> From there, it's an entirely plausible step to also require the `as`
> prefix on capture patterns in sequence patterns and as top level
> standalone patterns.
>
> I personally don't think that extra step would be a good idea due to
> the inconsistency with name binding and iterable unpacking in regular
> assignment statements (if I liked the idea, I'd have already included
> it in PEP 642), but I think "anchor match patterns in normal
> expressions rather than assignment target syntax" is a credible enough
> idea that the overall design process would benefit from having a
> champion write it up.
>
> > To me these read better than the punctuation characters.  But I guess
> some folks have suggested enlisting 'as', which is a word, of course.
>
> Indeed, and one that doesn't look too bad for top level patterns:
>
> NOT_FOUND = 404
> match http_code:
>   case 200:
>   print("OK document")
>   case NOT_FOUND:  # use the variable value
>   print("Document not found")
>   case as other_code:  # bind this name
>   print("Other HTTP code")
>
> It starts to look a bit more strange when matching sequences, though:
>
> match seq:
> case as first, *middle, as last:
> ... # Or should that be "*as middle"?
>

Although the spacing there should probably remain optional, I think
that "* as middle" is very straightforward and easy to read.


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/GFVLLQVHN2QWNX6LWHESBGRMXHLF3Z74/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Nick Coghlan]

On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
>
> I have read a great deal of discussion on the pattern matching PEPs and less 
> formal discussions.  It is possible I have overlooked some post in all of 
> that, of course.
>
> ... OK, just saw Guido's "wait for new SC" comment, which I suppose applies 
> to this too :-).
>
> One idea that I cannot recall seeing, but that seems to make sense to me and 
> fit with Python's feel is using a WORD to distinguish between a variable 
> value and a binding target.  That is, instead of a special symbol prefixing 
> or suffixing a name, either to indicate it is or is not a binding target.  Of 
> course, whether the extra word would be used for binding or for NOT binding 
> is a question still.

If someone was prepared to pursue this to the level of writing a 3rd
competing PEP, the variant I would personally like to see written up
is the one where capture patterns are all prefixed with the keyword
`as`.

PEP 634 already uses the `PATTERN as NAME` syntax to combine other
match patterns with a capture pattern, and I'm going to be amending
PEP 642 to propose using `as` when embedding capture patterns inside
class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
>From there, it's an entirely plausible step to also require the `as`
prefix on capture patterns in sequence patterns and as top level
standalone patterns.

I personally don't think that extra step would be a good idea due to
the inconsistency with name binding and iterable unpacking in regular
assignment statements (if I liked the idea, I'd have already included
it in PEP 642), but I think "anchor match patterns in normal
expressions rather than assignment target syntax" is a credible enough
idea that the overall design process would benefit from having a
champion write it up.

> To me these read better than the punctuation characters.  But I guess some 
> folks have suggested enlisting 'as', which is a word, of course.

Indeed, and one that doesn't look too bad for top level patterns:

NOT_FOUND = 404
match http_code:
  case 200:
  print("OK document")
  case NOT_FOUND:  # use the variable value
  print("Document not found")
  case as other_code:  # bind this name
  print("Other HTTP code")

It starts to look a bit more strange when matching sequences, though:

match seq:
case as first, *middle, as last:
... # Or should that be "*as middle"?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Thu, 12 Nov 2020 19:38:38 -0400
David Mertz  wrote:

[]
> One idea that I cannot recall seeing, but that seems to make sense to
> me and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special

> case value NOT_FOUND:  # use the variable value
> print("Document not found")

> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")

> To me these read better than the punctuation characters.  But I guess
> some folks have suggested enlisting 'as', which is a word, of course.

This is too verbose, COBOL-style. The whole push is to find concise,
yet intuitive and visible "sigils" for one possibility vs another, then
see how all 3 options (3rd being what's encoded in PEP634, sigil-less,
but with adhoc syntactic constraints) look and feel.

[]

-- 
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/6JZSRTETXPXFXGVYVTRT4SCQXHVP4DHG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Luciano Ramalho]

On Thu, Nov 12, 2020 at 8:41 PM David Mertz  wrote:
> One idea that I cannot recall seeing, but that seems to make sense to me and 
> fit with Python's feel is using a WORD to distinguish between a variable 
> value and a binding target.  That is, instead of a special symbol prefixing 
> or suffixing a name, either to indicate it is or is not a binding target.  Of 
> course, whether the extra word would be used for binding or for NOT binding 
> is a question still.

I agree 100%. Words instead of sigils is more like the rest of Python.

Best,

Luciano


>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case value NOT_FOUND:  # use the variable value
> print("Document not found")
> case OTHER_CODE:  # bind this name
> print("Other HTTP code", OTHER_CODE)
>
> Of course, this would require a soft keyword, which is a disadvantage.  Going 
> the other direction:
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case NOT_FOUND:  # use the variable value
> print("Document not found")
> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")
>
> To me these read better than the punctuation characters.  But I guess some 
> folks have suggested enlisting 'as', which is a word, of course.
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> 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/5YUWE7K6LX3VZIISURABRBCEIGMYDUCS/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/SNOU3YVKLQDA4SUBWX5L22XEGSKZBIVX/
Code of Conduct: http://python.org/psf/codeofconduct/