Mailing List Archive

On 11 Jul 2020, at 21:03, Eric Nieuwland <eric.nieuwland@gmail.com> wrote:

> What I meant to say is that as I read the current PEP text there would be a confusing difference between
>
> match poly:
> case Polygon(Point(x0, y0), Point(x1, y1), Point(x2, y2)):
> ...
>
> and
>
> p0 = Point(x0, y0)
> p1 = Point(x1, y1)
> p2 = Point(x2, y2)
> match poly:
> case Polygon(p0, p1, p2):
> ...
>
> This would be especially clumsy if I need to match parts in a deep structure.
> It would require me to either write the whole construction as part of the ‘match’ or use ‘match’ nested to drill down to the parts I need.
>

Just after I hit ‘send’ it dawned on me it might be preferable to make that

match poly:
p0 = Point(x0, y0)
p1 = Point(x1, y1)
p2 = Point(x2, y2)
case Polygon(p0, p1, p2):
…

so the part preceded by ‘match’ is the preparation phase for matching.

This could also resolve the discussion on indentation of the ‘case’ parts and the placement of the default matching:

match <expression> [as <var>]:
<preparation statements>
case <pattern> [<guard>]:
<statements>
…
[else:
<statements>]

within the preparation statements it would then be allowed to use undefined variables as receivers of matched parts.
_______________________________________________
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/DOGIGJRL2RBHNGXXH2LZG6QMWTPLHU5J/
Code of Conduct: http://python.org/psf/codeofconduct/

Given that case will be a keyword, what's the case (pun unintentional) for
indenting the case clauses? What's wrong with 'case' and 'else' both
indented the same as match? Without the keyword there'd be a case for
indenting, but with it I don't see the necessity.

Kind regards,
Steve


On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:

> A thought about the indentation level of a speculated "else" clause...
>
> Some people have argued that "else" should be at the outer level,
> because that's the way it is in all the existing compound statements.
>
> However, in those statements, all the actual code belonging to the
> statement is indented to the same level:
>
> if a:
> ....
> elif b:
> ....
> else:
> ....
>
> ^
> |
> Code all indented to this level
>
> But if we were to indent "else" to the same level as "match",
> the code under it would be at a different level from the rest.
>
> match a:
> case 1:
> ....
> case 2:
> ....
> else:
> ....
> ^ ^
> | |
> Code indented to two different levels
>
> This doesn't seem right to me, because all of the cases, including
> the else, are on the same footing semantically, just as they are in
> an "if" statement.
>
> --
> Greg
> _______________________________________________
> 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/ACH4QXCURTNEGKFQXEWET5NQ6DIABSQZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On 2020-07-11 20:56, Steve Holden wrote:
> Given that case will be a keyword, what's the case (pun unintentional)
> for indenting the case clauses? What's wrong with 'case' and 'else' both
> indented the same as match? Without the keyword there'd be a case for
> indenting, but with it I don't see the necessity.
>
> Kind regards,
> Steve
>
The issue is as follows.

In Python, the style is that multi-line statements start with a keyword
and that logical line ends with a colon. The next line is a statement,
which is indented. The other parts of the statement structure are
indented the same amount as its first line:

if ...:
...
elif ...:
...
else:
...

The 'match' statement (or a 'switch' statement), however, can't follow
the existing style.

It's either:

match ...:
case ...:
case ...:

where the second line isn't indented (unlike all other structures), or:

match ...:
case ...:
case ...:

where the other parts of the structure (the cases) aren't indented the
same as the first line.

Another possibility is:

match:
...
case ...:
case ...:

but the second line is an expression, not a statement (unlike all other
structures).

An alternative is:

match ...
case ...:
case ...:

no colon ending the first line, and no indenting of the second line, but
that's unlike all other structures too.

None of the possibilities are formatted like the existing style.

So it's a case of picking the least inelegant one.

>
> On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing <greg.ewing@canterbury.ac.nz
> <mailto:greg.ewing@canterbury.ac.nz>> wrote:
>
> A thought about the indentation level of a speculated "else" clause...
>
> Some people have argued that "else" should be at the outer level,
> because that's the way it is in all the existing compound statements.
>
> However, in those statements, all the actual code belonging to the
> statement is indented to the same level:
>
>      if a:
>          ....
>      elif b:
>          ....
>      else:
>          ....
>
>          ^
>          |
>          Code all indented to this level
>
> But if we were to indent "else" to the same level as "match",
> the code under it would be at a different level from the rest.
>
>      match a:
>          case 1:
>              ....
>          case 2:
>              ....
>      else:
>          ....
>          ^   ^
>          |   |
>          Code indented to two different levels
>
> This doesn't seem right to me, because all of the cases, including
> the else, are on the same footing semantically, just as they are in
> an "if" statement.
>
_______________________________________________
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/M4YMCRVSKVKNUXQFI5KOMT5MQH6WJ23O/
Code of Conduct: http://python.org/psf/codeofconduct/

On 07/11/2020 10:29 AM, Jim J. Jewett wrote:
> To me, "else:" has a slightly different meaning than "case _:"
>
> case _: essentially a default, ensuring that the match logic is complete.
>
> else: OK, the subject of this match failed, here is our fallback logic.
>
> Whether this distinction is important enough to express in code is another question, as is whether or not anyone but me would follow this "obvious" convention. So I'm not convinced the difference justifies the existence a second syntax. But I'm also not sure it doesn't, particularly if that distinction were given in the PEP and in documentation for the match statement.

This is exactly how I would use it.

--
~Ethan~
_______________________________________________
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/K67GGYLNLL7C5A7SIQF6PFQQUOGEKCRF/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman <ethan@stoneleaf.us> wrote:

> On 07/11/2020 10:29 AM, Jim J. Jewett wrote:
> > To me, "else:" has a slightly different meaning than "case _:"
> >
> > case _: essentially a default, ensuring that the match logic
> is complete.
> >
> > else: OK, the subject of this match failed, here is our fallback
> logic.
> >
> > Whether this distinction is important enough to express in code is
> another question, as is whether or not anyone but me would follow this
> "obvious" convention. So I'm not convinced the difference justifies the
> existence a second syntax. But I'm also not sure it doesn't, particularly
> if that distinction were given in the PEP and in documentation for the
> match statement.
>
> This is exactly how I would use it.
>

Hm... Just the fact that people have been arguing both sides so
convincingly makes me worry that something bigger is amiss. I think we're
either better off without `else` (since the indentation of `case _` cannot
be disputed :-), or we have to revisit the reasons for indenting `case`
relative to `match`. As MRAB said, it's a case of picking the least
inelegant one.

Let me add that the parser can easily deal with whatever we pick -- this is
purely about human factors.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On 11/07/20 11:20 pm, Paul Sokolovsky wrote:
> On Sat, 11 Jul 2020 22:49:09 +1200
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>
>> or like this:
>>
>> switch (x) {
>> case 1:
>> ...
>> case 2:
>> ...
>> default:
>> ...
>> }
>
> Oh really, you never saw that? Well, they say that any programmer
> should eyeball the source code of the most popular open-source OS at
> least once:
> https://elixir.bootlin.com/linux/latest/source/kernel/sys.c#L2144

I stand corrected -- it seems I haven't looked at other people's
switch statements all that much.

I can see that being a reasonable choice if you're using 8-space
indents, but I don't see that done much in Python.

Also, directly translating this into Python leads to something that
looks like a mistake:

match x:
case 1:
...
case 2:
...

and as has been pointed out, the alternative of putting x on the
next line is unprecedented in Python.

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

Just had another thought about marking assignment targets.

The PEP currently forbids repeating bound names in a pattern
to avoid raising expectations that

case Point(x, x):

would match only if the two arguments were equal.

But if assignment targets were marked, we could write this as

case Point(?x, x):

and it would work as expected.

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

On 12/07/20 7:03 am, Federico Salerno wrote:
> On 11/07/2020 12:49, Greg Ewing wrote:
>> ?? switch (x) {
>> ?? case 1:
>> ????? ...
>> ?? case 2:
>> ????? ...
>> ?? default:
>> ????? ...
>> ?? }
>
> I think that last one would be perceived as ok if it weren't for the
> brackets: everyone naturally indents any set of brackets' contents.

Equally, in Python, everyone naturally indents anything that comes
after a colon.

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

On 12/07/20 7:13 am, Eric Nieuwland wrote:
> match poly:
> p0 = Point(x0, y0)
> p1 = Point(x1, y1)
> p2 = Point(x2, y2)
> case Polygon(p0, p1, p2):
> …

Interesting idea, but what happens if you *don't* need any setup?
Do you have to write

match poly:
pass
case ...

?

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

On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>
> Just had another thought about marking assignment targets.
>
> The PEP currently forbids repeating bound names in a pattern
> to avoid raising expectations that
>
> case Point(x, x):
>
> would match only if the two arguments were equal.
>
> But if assignment targets were marked, we could write this as
>
> case Point(?x, x):
>
> and it would work as expected.
>

Hang on. Matching happens before assignment, so this should use the
previous value of x for the matching. At least, that's my
understanding. If you do something like:

case Point(x, 2):

it won't assign x unless the second coordinate is 2, right?

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

On Sat, Jul 11, 2020 at 5:28 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:

> Just had another thought about marking assignment targets.
>
> The PEP currently forbids repeating bound names in a pattern
> to avoid raising expectations that
>
> case Point(x, x):
>
> would match only if the two arguments were equal.
>
> But if assignment targets were marked, we could write this as
>
> case Point(?x, x):
>
> and it would work as expected.
>

Yes. And if instead we marked name loads, e.g. with `^name`, we could write
it as
```
case Point(x, ^x):
```
In fact, Elixir's "pin" operator is `^` and works this way.

I don't find it very intuitive that in order to write "it should be the
same x twice" you have to spell it differently -- it's more a clever trick
(that surely would become a hacker's idiom if we allowed it).

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing <greg.ewing@canterbury.ac.nz>
> wrote:
> >
> > Just had another thought about marking assignment targets.
> >
> > The PEP currently forbids repeating bound names in a pattern
> > to avoid raising expectations that
> >
> > case Point(x, x):
> >
> > would match only if the two arguments were equal.
> >
> > But if assignment targets were marked, we could write this as
> >
> > case Point(?x, x):
> >
> > and it would work as expected.
>
> Hang on. Matching happens before assignment, so this should use the
> previous value of x for the matching. At least, that's my
> understanding. If you do something like:
>
> case Point(x, 2):
>
> it won't assign x unless the second coordinate is 2, right?
>

Good catch. That's actually undefined -- we want to let the optimizer have
some leeway in how to generate the best code for matching. See
https://www.python.org/dev/peps/pep-0622/#performance-considerations

Currently it doesn't optimize all that much -- it just processes patterns
from left to right:
```
>>> match Point(3, 3):
... case Point(x, 42): pass
...
>>> print(x)
3
>>>
```

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

> On 07/11/2020 10:29 AM, Jim J. Jewett wrote:
>> To me, "else:" has a slightly different meaning than "case _:"
>>
>>          case _:  essentially a default, ensuring that the match logic
>> is complete.
>>
>>      else:  OK, the subject of this match failed, here is our fallback
>> logic.

Is there anywhere else where Python goes out of its way
to provide two ways of doing the same thing just because
they might feel semantically different?

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

On Sun, Jul 12, 2020 at 11:04 AM Guido van Rossum <guido@python.org> wrote:
>
> On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> >
>> > Just had another thought about marking assignment targets.
>> >
>> > The PEP currently forbids repeating bound names in a pattern
>> > to avoid raising expectations that
>> >
>> > case Point(x, x):
>> >
>> > would match only if the two arguments were equal.
>> >
>> > But if assignment targets were marked, we could write this as
>> >
>> > case Point(?x, x):
>> >
>> > and it would work as expected.
>>
>> Hang on. Matching happens before assignment, so this should use the
>> previous value of x for the matching. At least, that's my
>> understanding. If you do something like:
>>
>> case Point(x, 2):
>>
>> it won't assign x unless the second coordinate is 2, right?
>
>
> Good catch. That's actually undefined -- we want to let the optimizer have some leeway in how to generate the best code for matching. See https://www.python.org/dev/peps/pep-0622/#performance-considerations
>
> Currently it doesn't optimize all that much -- it just processes patterns from left to right:
> ```
> >>> match Point(3, 3):
> ... case Point(x, 42): pass
> ...
> >>> print(x)
> 3
> >>>
> ```
>

Ah, okay. My "obvious" intuition was that this wouldn't assign, and
Greg's equally "obvious" intuition was that it would. I think that
disagreement should be a strike against the "Point(?x, x)" notation -
I can't be the only person who would misinterpret it.

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

On 2020-07-12 01:32, Chris Angelico wrote:
> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>>
>> Just had another thought about marking assignment targets.
>>
>> The PEP currently forbids repeating bound names in a pattern
>> to avoid raising expectations that
>>
>> case Point(x, x):
>>
>> would match only if the two arguments were equal.
>>
>> But if assignment targets were marked, we could write this as
>>
>> case Point(?x, x):
>>
>> and it would work as expected.
>>
>
> Hang on. Matching happens before assignment, so this should use the
> previous value of x for the matching. At least, that's my
> understanding. If you do something like:
>
> case Point(x, 2):
>
> it won't assign x unless the second coordinate is 2, right?
>
Presumably the assumption is that it would use a local dict for binding,
faling back to the actual dict if necessary for lookup, and then update
the actual dict if the match is successful. That way, unsuccessful
matches won't pollute the actual dict.
_______________________________________________
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/OUT2EZB5VMWT4VGJCGF7DAWMTNJAVHRT/
Code of Conduct: http://python.org/psf/codeofconduct/

On 12/07/2020 02:04, Guido van Rossum wrote:
> On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico <rosuav@gmail.com
> <mailto:rosuav@gmail.com>> wrote:
>
>
> Hang on. Matching happens before assignment, so this should use the
> previous value of x for the matching. At least, that's my
> understanding. If you do something like:
>
> case Point(x, 2):
>
> it won't assign x unless the second coordinate is 2, right?
>
>
> Good catch. That's actually undefined -- we want to let the optimizer
> have some leeway in how to generate  the best code for matching. See
> https://www.python.org/dev/peps/pep-0622/#performance-considerations
>
> Currently it doesn't optimize all that much -- it just processes
> patterns from left to right:
> ```
> >>> match Point(3, 3):
> ...   case Point(x, 42): pass
> ...
> >>> print(x)
> 3
> >>>
> ```
>
If I've understood this correctly, my immediate reaction is one of
horror.  I'd assumed that a case that failed to match would have no effect.
Rob Cliffe

I don't think anyone has asked for more indentation in that sense; it has only even come up in a suggestion of less. (2-space indents for case instead of 4)

People do disagree about whether or not case statements (and possibly an else statement) should be indented more than 0 spaces compared to match.
_______________________________________________
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/5R5WLOZE5HNJUIMDEPXQ73XMMHJL7XVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

On 7/8/20 8:02 AM, Guido van Rossum wrote:
> Regarding the syntax for wildcards and OR patterns, the PEP explains
> why `_` and `|` are the best choices here: no other language surveyed
> uses anything but `_` for wildcards, and the vast majority uses `|`
> for OR patterns.  A similar argument applies to class patterns.


In that case, I'd like to make a specific pitch for "don't make '_'
special".  (I'm going to spell it '_' as it seems to be easier to read
this way; ignore the quotes.)


IIUC '_' is special in two ways:

1) we permit it to be used more than once in a single pattern, and
2) if it matches, it isn't bound.

If we forego these two exceptions, '_' can go back to behaving like any
other identifier.  It becomes an idiom rather than a special case.


Drilling down on what we'd need to change:

To address 1), allow using a name multiple times in a single pattern.

622 v2 already says:

For the moment, we decided to make repeated use of names within the
same pattern an error; we can always relax this restriction later
without affecting backwards compatibility.

If we relax it now, then we don't need '_' to be special in this way. 
All in all this part seems surprisingly uncontentious.


To address 2), bind '_' when it's used as a name in a pattern.

This adds an extra reference and an extra store.  That by itself seems
harmless.

The existing implementation has optimizations here.  If that's
important, we could achieve the same result with a little dataflow
analysis to optimize away the dead store.  We could even special-case
optimizing away dead stores /only/ to '_' and /only/ in match/case
statements and all would be forgiven.

Folks point out that I18N code frequently uses a global function named
'_'.  The collision of these two uses is unfortunate, but I think it's
survivable.  I certainly don't think this collision means we should
special-case this one identifier in this one context in the /language/
specification.

Consider:

* There's no installed base of I18N code using pattern matching,
because it's a new (proposed!) syntax.  Therefore, any I18N code
that wants to use match/case statements will be new code, and so can
be written with this (admittedly likely!) collision in mind.  I18N
code could address this in several ways, for example:
o Mandate use of an alternate name for "don't care" match patterns
in I18N code, perhaps '__' (two underscores).  This approach
seems best.
o Use a different name for the '_' function in scopes where you're
using match/case, e.g. 'gettext'.
o Since most Python code lives inside functions, I18N code could
use '_' in its match/case statements, then "del _" after the
match statement.  '_' would revert back to finding the global
function.  (This wouldn't work for code at module scope for
obvious reasons.  One /could/ simply rebind '_', but I doubt
people want to consider this approach in the first place.)
* As the PEP mentions, '_' is already a Python idiom for "I don't care
about this value", e.g. "basename, _, extension =
filename.partition('.')".  I18N has already survived contact with
this idiom.
* Similarly, '_' has a special meaning in the Python REPL. Admittedly,
folks don't use a lot of I18N work in the REPL, so this isn't a
problem in practice.  I'm just re-making the previous point: I18N
programmers already cope with other idiomatic uses of '_'.
* Static code analyzers could detect if users run afoul of this
collision.  "Warning: match/case using _ in module using _ for
gettext" etc.


One consideration: if you /do/ use '_' multiple times in a single
pattern, and you /do/ refer to its value afterwards, what value should
it get?  Consider that Python already permits multiple assignments in a
single expression:

(x:="first", x:="middle", x:="last")

After this expression is evaluated, x has been bound to the value
"last".  I could live with "it keeps the rightmost".  I could also live
with "the result is implementation-defined".  I suspect it doesn't
matter much, because the point of the idiom is that people don't care
about the value.


In keeping with this change, I additionally propose removing '*_' as a
special token.  '*_' would behave like any other '*identifier', binding
the value to the unpacked sequence. Alternately, we could keep the
special token but change it to '*' so it mirrors Python function
declaration syntax.  I don't have a strong opinion about this second
alternative.


Cheers,


//arry/

On 12/07/2020 11:38, Larry Hastings wrote:
> In that case, I'd like to make a specific pitch for "don't make '_'
> special".  (I'm going to spell it '_' as it seems to be easier to read
> this way; ignore the quotes.)
>
> IIUC '_' is special in two ways:
>
> 1) we permit it to be used more than once in a single pattern, and
> 2) if it matches, it isn't bound.
>
> If we forego these two exceptions, '_' can go back to behaving like
> any other identifier.  It becomes an idiom rather than a special case.
>
> Drilling down on what we'd need to change:
>
> To address 1), allow using a name multiple times in a single pattern.
>
> 622 v2 already says: [...]
>
> If we relax it now, then we don't need '_' to be special in this way. 
> All in all this part seems surprisingly uncontentious.
>
> To address 2), bind '_' when it's used as a name in a pattern.
>
> This adds an extra reference and an extra store.  That by itself seems
> harmless.
>
> The existing implementation has optimizations here.  If that's
> important, we could achieve the same result with a little dataflow
> analysis to optimize away the dead store.  We could even special-case
> optimizing away dead stores /only/ to '_' and /only/ in match/case
> statements and all would be forgiven.
>
> Folks point out that I18N code frequently uses a global function named
> '_'.  The collision of these two uses is unfortunate, but I think it's
> survivable.  I certainly don't think this collision means we should
> special-case this one identifier in this one context in the /language/
> specification.
>
> Consider:
>
> * There's no installed base of I18N code using pattern matching,
> because it's a new (proposed!) syntax.  Therefore, any I18N code
> that wants to use match/case statements will be new code, and so
> can be written with this (admittedly likely!) collision in mind.
> I18N code could address this in several ways, for example:
> o Mandate use of an alternate name for "don't care" match
> patterns in I18N code, perhaps '__' (two underscores).  This
> approach seems best.
>
> In keeping with this change, I additionally propose removing '*_' as a
> special token.  '*_' would behave like any other '*identifier',
> binding the value to the unpacked sequence.  Alternately, we could
> keep the special token but change it to '*' so it mirrors Python
> function declaration syntax.  I don't have a strong opinion about this
> second alternative.

+1 to everything

> One consideration: if you /do/ use '_' multiple times in a single
> pattern, and you /do/ refer to its value afterwards, what value should
> it get? Consider that Python already permits multiple assignments in a
> single expression:
>
> (x:="first", x:="middle", x:="last")
>
> After this expression is evaluated, x has been bound to the value
> "last".  I could live with "it keeps the rightmost".  I could also
> live with "the result is implementation-defined".  I suspect it
> doesn't matter much, because the point of the idiom is that people
> don't care about the value.
>
I'd expect it to bind to the last one. If that's in any way problematic,
in order to prevent oblivious misuse, referencing an identifier that was
bound more than once should raise an exception. But as you say, it
doesn't really matter.

On 11/07/2020 20:13, Eric Nieuwland wrote:
> Just after I hit ‘send’ it dawned on me it might be preferable to make that
>
> match poly:
> p0 = Point(x0, y0)
> p1 = Point(x1, y1)
> p2 = Point(x2, y2)
> case Polygon(p0, p1, p2):
> …
>
> so the part preceded by ‘match’ is the preparation phase for matching.

Are you intending p0, p1 and p2 to be subpatterns rather than object
instantiations? That makes me a little twitchy; the difference between
what you wrote and:

match poly:
p0 = Point(x0, y0)
p1 = Point(x1, y1)
case Polygon(p0, p1, p2):
...

is very easy to miss.

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

On 11/07/2020 12:20, Paul Sokolovsky wrote:
> Actually, the whole argument in PEP 622 regarding "else:", that its
> placement is ambiguous sounds like a rather artificial write-off.
> Individual "case"'s are aligned together, but suddenly, it's unclear
> how to align the default case, introduced by "else"? Who in good faith
> would align it with "match"?

I would, if I'd used an "else" with a "for" recently. I would have a
strong tendency to align the "else" with the "case" statements, but I
can see how the other way around makes sense too.

(I can't see how anyone likes the Linux case indentation style at all.
It's horrible to read.)

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

On Sun, 12 Jul 2020 at 10:47, Larry Hastings <larry@hastings.org> wrote:
> In that case, I'd like to make a specific pitch for "don't make '_' special". (I'm going to spell it '_' as it seems to be easier to read this way; ignore the quotes.)

Overall, this sounds mostly reasonable. I'm cutting nearly everything
here, because I don't have anything to add.

> One consideration: if you do use '_' multiple times in a single pattern, and you do refer to its value afterwards, what value should it get? Consider that Python already permits multiple assignments in a single expression:
>
> (x:="first", x:="middle", x:="last")
>
> After this expression is evaluated, x has been bound to the value "last". I could live with "it keeps the rightmost". I could also live with "the result is implementation-defined". I suspect it doesn't matter much, because the point of the idiom is that people don't care about the value.

The problem for me is specifically with variables *other* than `_` -
precisely because `_` has connotations of "don't care".

If I see

match expr:
case Point(x, x):
# what is x here?

I would very strongly expect that to mean that the two components of
Point were equal, and x was set to the common value. That's not what
Python does, so this would be a fairly easy mistake to make.

For what it's worth, it looks like Rust uses the same rule as the PEP
- multiple occurrences of the same variable are not allowed, but _ is
a wildcard that *can* be used multiple times, but isn't bound.
Paul
_______________________________________________
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/EC6MQQ6BKU6Y2KN5R6V2CEWJQ5I3NQO6/
Code of Conduct: http://python.org/psf/codeofconduct/

Hey Larry, just to clarify on a single point you make:

On Sun, 12 Jul 2020 at 10:48, Larry Hastings <larry@hastings.org> wrote:

> [ snip ]
> To address 2), bind '_' when it's used as a name in a pattern.
>
> This adds an extra reference and an extra store. That by itself seems
> harmless.
>

This is not always just a store. for patterns like `[a, *_, b]` vs `[a,
*ignore_me, b]`, the current semantics mean that the matching process has
to make 2 calls to `__getitem__` on the match subject. The second case
(which would be equivalent to "remove special meaning on _") will have to
actually create a new list and copy most of the original one which can be
arbitrarily long, so this turns an O(1) operation into O(n).

> The existing implementation has optimizations here. If that's important,
> we could achieve the same result with a little dataflow analysis to
> optimize away the dead store. We could even special-case optimizing away
> dead stores *only* to '_' and *only* in match/case statements and all
> would be forgiven.
>
This might work, although it's quite different to what python does in
general (are you supposed to see the value of `_` in a debugger? or in
`locals()`? )

Cheers,
D.

Greg Ewing wrote:
> Eric Nieuwland wrote:
>
>> ...
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p1, p2):
>> …
>>
>
> Interesting idea, but what happens if you don't
> need any setup?
> Do you have to write
>
>
> match poly:
> pass
> case ...
>
> ?

Yes, that would be the idea.

Unless you would need to setup variables to be bound in the cases, of course.
Without that an if … elif … elif … else structure would be equivalent and possibly preferable.
_______________________________________________
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/CMDHKH3YPLIQ4WGI4MEL2BQKKVU6DGDE/
Code of Conduct: http://python.org/psf/codeofconduct/

Rhodri James wrote:

> Eric Nieuwland wrote:
>
>> Just after I hit ‘send’ it dawned on me it might be preferable to make that
>>
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p1, p2):
>> …
>>
>> so the part preceded by ‘match’ is the preparation phase for matching.
>>
> Are you intending p0, p1 and p2 to be subpatterns rather than object instantiations? That makes me a little twitchy; the difference between what you wrote and:
>
> match poly:
> p0 = Point(x0, y0)
> p1 = Point(x1, y1)
> case Polygon(p0, p1, p2):
> ...
> is very easy to miss.
>

You are perfectly right.
That is why I prefer explicit marking of variables to be bound by matching.
Your example could then become:

match poly:
p0 = Point(x0, \y0)
p1 = Point(\x1, y1)
case Polygon(p0, p1, \p2):
…

and IMHO it would be very clear what to expect.

An alternative would be to ‘declare’ variables that are to be bound to make things even more explicit, like:

match poly:
x1 = to_be_bound_by_matching
y0 = to_be_bound_by_matching
p2 = to_be_bound_by_matching
p0 = Point(x0, y0)
p1 = Point(x1, y1)
case Polygon(p0, p1, p2):
…

where a better name than ‘to_be_bound_by_matching’ would certainly be needed.

—eric
_______________________________________________
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/W6VILFGBO4HJLEAUTSW6SJMNZN352KTJ/
Code of Conduct: http://python.org/psf/codeofconduct/