[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

On 11/07/20 10:35 am, Federico Salerno wrote:
I feel all those who aren't directly arguing against it are working off 
the assumption that it is needed for match and case to have different 
levels of indentation, but is this really true? Is there anything (bar 
tradition or other subjective arguments) that speaks in favour of this,


I can't think of one at the moment, but I don't think you
should dismiss tradition so easily. One of the arguments used
to justify significant indentation in Python is that "you're
going to indent it for readability anyway, so the compiler
might as well take notice of it".

For the most part, Python indentation follows what people
would naturally do even if they didn't have to. So I think it's
worth looking at what people typically do in other languages
that don't have mandatory indentation.

Taking C, for example, switch statements are almost always
written like this:

   switch (x) {
  case 1:
 ...
  case 2:
 ...
  default:
 ...
   }

I've rarely if ever seen one written like this:

   switch (x) {
  case 1:
 ...
  case 2:
 ...
   default:
  ...
   }

or like this:

   switch (x) {
   case 1:
  ...
   case 2:
  ...
   default:
  ...
   }

This suggests to me that most people think of the cases as being
subordinate to the switch, and the default being on the same level
as the other cases.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Paul Sokolovsky]

Hello,

On Sat, 11 Jul 2020 22:49:09 +1200
Greg Ewing  wrote:

[]

> For the most part, Python indentation follows what people
> would naturally do even if they didn't have to. So I think it's
> worth looking at what people typically do in other languages
> that don't have mandatory indentation.
> 
> Taking C, for example, switch statements are almost always
> written like this:
> 
> switch (x) {
>case 1:
>   ...
>case 2:
>   ...
>default:
>   ...
> }
> 
> I've rarely if ever seen one written like this:
> 
> switch (x) {
>case 1:
>   ...
>case 2:
>   ...
> default:
>...
> }

Indeed, that's unheard of (outside of random pupil dirtcode).

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"?
 

> 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

And a lot of projects follow the Linux codestyle, because it's
familiar to many people and offers ready/easy to use infrastructure for
code style control.

> This suggests to me that most people think of the cases as being
> subordinate to the switch, and the default being on the same level
> as the other cases.

And to me it suggests that well established projects, which have
thought out it all, aren't keen to use more indentation than really
needed.

> -- 
> Greg

[]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Ethan Furman]

On 07/11/2020 04:20 AM, 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.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Paul Moore]

On Sat, 11 Jul 2020 at 14:39, Ethan Furman  wrote:
>
> On 07/11/2020 04:20 AM, 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.

How do you feel about the fact that

match EXPR:
case 1:
print("One")
case _:
print("default")

and

match EXPR:
case 1:
print("One")
else:
print("default")

are semantically completely identical, but syntactically must be
indented differently? That for me is probably the most compelling
reason for preferring to indent else to the same level as case¹. I'm
curious to understand how people who prefer aligning else with match
view this. (Not least, because I anticipate some "interesting" code
style flamewars over this ;-))

Paul

¹ When I say "most compelling" I mean "inclines me to have a mild
preference" :-) In reality I mostly don't care, and I'll probably just
use "case _" in any projects I work on and ignore the existence of
"else" altogether.
___
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/ZM6CQQ4W2Q3S3NKFHPPWZHJPK3FNHJJW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim J. Jewett]

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.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim J. Jewett]

Glenn Linderman wrote:
> On 7/10/2020 3:15 AM, Gustavo Carneiro wrote:
...
> > Therefore, I posit that the style of try...except indentation only 
> > works where the number of cases is small.
> > But for the case of pattern matching, I expect the number of cases to 
> > be matched to be a lot higher than exception handling cases.  Having 
> > cases to be matched be indented is, IMHO, a nice visual cue to help 
> > the reader understand where the pattern matching block ends.

> Actually, the current  if elseif elseif elseif else, used now because 
> Python has no switch/match/case, has exactly the same issue as you 
> describe as a problem with try if there were more cases... and if often 
> has more cases, just like match will.

True

> So your concern seems nebulous. You may have wished for extra 
> indentation but it is simple to get more indentation: use 8 spaces 
> instead of 4. So if you really wanted it, you could have had it.

Not so true. 

if a: ...
elif b: ...
elif c: ...
else:

is not valid.  In practice, I interpret wanting to indent at a place that 
doesn't require it as a code smell suggesting I should try to break out a 
helper function, but ... it does happen.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Glenn Linderman]

On 7/11/2020 10:36 AM, Jim J. Jewett wrote:

Glenn Linderman wrote:

On 7/10/2020 3:15 AM, Gustavo Carneiro wrote:

...

Therefore, I posit that the style of try...except indentation only
works where the number of cases is small.
But for the case of pattern matching, I expect the number of cases to
be matched to be a lot higher than exception handling cases.  Having
cases to be matched be indented is, IMHO, a nice visual cue to help
the reader understand where the pattern matching block ends.

Actually, the current  if elseif elseif elseif else, used now because
Python has no switch/match/case, has exactly the same issue as you
describe as a problem with try if there were more cases... and if often
has more cases, just like match will.

True


So your concern seems nebulous. You may have wished for extra
indentation but it is simple to get more indentation: use 8 spaces
instead of 4. So if you really wanted it, you could have had it.

Not so true.


It is true, the way I meant it, but not the way you (mis-)interpreted it.


 if a: ...
 elif b: ...
 elif c: ...
 else:

is not valid.  In practice, I interpret wanting to indent at a place that 
doesn't require it as a code smell suggesting I should try to break out a 
helper function, but ... it does happen.


if  a:
    ...
elif b:
    ...
elif c:
    ...
else:
    ...

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Federico Salerno]

On 11/07/2020 00:57, Paul Sokolovsky wrote:

The PEP itself in "rejected" ideas makes an argument against it:
indented stuff after a line ending with ":" must be a *statement*. It 
would be totally nuts for that to be something else, e.g. an expression:

Good point.

That of course leads us to the obvious idea:
match a: case 1:     ... case 2:     ... else:     ... Of course, PEP 
smartly has an argument against that too, in the vein of "after line 
ending with ':', there should be an indent suite (list of 
statements)". But that's where it goes sideways.


Exactly. I think not identing what comes after match a: comes with far 
more advantages than disadvantages. In fact, if the only "real" issue is 
that anything after : must be indented, I'd say it is vastly outweighed 
by the issues not doing it would solve.


Would the parser allow us to write the above without the colon, thus 
avoiding the aforementioned objection?


And if the above snippet looks weird to anybody, it's only because of 
all the "case" business. There wouldn't be such a problem if it was 
instead: match a: | 1:     ... | 2:     ... |:     ... The above 
ML-like syntax should be perfect for almost everyone, ... except the 
PEP authors, because they have it in "rejected ideas" either.


I don't know, that doesn't look very pythonic based on the preference 
Python makes for words over symbols. I don't think there's any problem 
with using case, it's the expectations many have for what should come 
around it that creates issues.


On 11/07/2020 12:49, Greg Ewing wrote:

I can't think of one at the moment, but I don't think you
should dismiss tradition so easily.


I don't mean to dismiss it, but I wouldn't want it to get in the way of 
a change if there are good reasons to go against tradition. This seems 
like one of these cases to me.



One of the arguments used
to justify significant indentation in Python is that "you're
going to indent it for readability anyway, so the compiler
might as well take notice of it".

For the most part, Python indentation follows what people
would naturally do even if they didn't have to. So I think it's
worth looking at what people typically do in other languages
that don't have mandatory indentation.

[...]

or like this:

   switch (x) {
   case 1:
  ...
   case 2:
  ...
   default:
  ...
   }

This suggests to me that most people think of the cases as being
subordinate to the switch, and the default being on the same level
as the other cases. 


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. I 
wouldn't normally mind cases being indented extra relative to "match" if 
not for two points:


1. Python relies heavily on indentation. It's likely for a match block 
to appear in a place that is already well indented, *and* it is also 
likely to often include further levels of indentation. It would be 
preferable not to require two levels at a minimum every time a match 
block is needed.


2. Unless the default case is signalled with an ad-hoc keyword like 
default (which I personally would like), it seems a wildcard symbol like 
the controversial _ is needed to pair with case. Going against tradition 
and setting only one indentation level would solve this issue, while 
still allowing (I think) any programmer to indent the default case extra 
if they so wish.


If none of this is convincing, I do believe the matter is easier than it 
appears, because few would be confused by else being at the same level 
as each other case.


Alternatively, what if (gasp!) both were allowed as synonyms? I'm sure 
one of the two would eventually settle as conventional, and there is no 
possible ambiguity. I know it goes against the "one obvious way to do 
it" precept but it's clear that there is no obvious way here at all, so, 
¿porque no los dos?
___
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/2U3DRD7R244V7SQ24WRUM34SENA3P5US/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Steve Holden]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Eric Nieuwland]

> On 10 Jul 2020, at 18:28, Jim Baker  wrote:
> 
> On Fri, Jul 10, 2020, 9:16 AM Eric Nieuwland  wrote:
> 
>> On 10 Jul 2020, at 01:51, Jim Baker  wrote:
>> ...
>> Explicit namespacing (if a constant) or using a guard (if a variable) seems 
>> to be the right solution, as Ethan demonstrated earlier. No need for . or ^ 
>> or  \ or ... to disambiguate. Also it seems to me that structural pattern 
>> matching will build on two common usages of namespaces for constants:
>> 
>> 1. Constants used from other modules are almost always used in the module 
>> namespace. Eg, socket.AF_UNIX or signal.SIGTERM.
>> 2. New code often tends to use constants defined within an Enum namespace. 
>> Hopefully we will see more of this convention in usage.
>> 
>> (Very much an aside: Interestingly with the socket module we see both used - 
>> it defines its constants with IntEnum and exports them traditionally. The 
>> namespace specifics it uses with IntEnum._convert_ to make this happen  -- 
>> strictly speaking EnumMeta._convert, not documented, and a bit hard to 
>> follow -- might be possibly debatable, but it works out quite well in 
>> practice in providing backwards compatibility while continuing to work with 
>> a C source of these constants.)
>>  
>> This would also mean
>> case Point(x=\x, y=\y):
>> should be used to obtain x and y from the Point instance.
> 
> This approach makes deeper nesting of the structure much more cumbersome, I 
> think.
> 
> How to match Polygon(Point(x0,y0), Point(x1, y1), Point(x2, y2)) based on its 
> structure?
> And Polygon(Point(x0,y0), p1, Point(x2, y2))?
> 
> 
>  I'm just trying to describe what v2 of the PEP is trying to do and how it 
> then corresponds to a reasonable usage model. Sorry for any confusion.

Yes, I understood. Thank you for that. No apology needed.

> So in your scenario above, Polygon and Point are used as class patterns 
> (https://www.python.org/dev/peps/pep-0622/#class-patterns). Consequently they 
> are treated accordingly and have that nice structural pattern matching 
> quality!

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.

> Earlier I was discussing constant patterns 
> (https://www.python.org/dev/peps/pep-0622/#constant-value-patterns), which 
> require they be namespaced in some way (a qualified name as it is described 
> in the PEP).

Indeed.
My point is this would be - as far as I know - the first time you need to 
create a namespace to use the value of an already known variable.
This only to allow assignment to variables which I find counterintuitive and 
which IMHO leads to clumsy constructions, as shown above.

So I hope the new and special thing here (i.e. assign matched parts of the 
structure to variables) will not interfere with how we read expressions in 
Python.
A special indicator for the special use case to me seems far easier to 
understand and to teach.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Eric Nieuwland]

On 11 Jul 2020, at 21:03, Eric Nieuwland  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  [as ]:

case  []:

…
[else:
]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Ethan Furman]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman  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?)*

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

On 11/07/20 11:20 pm, Paul Sokolovsky wrote:

On Sat, 11 Jul 2020 22:49:09 +1200
Greg Ewing  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-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/QWSYAU3WIXHG2TYKMGJTARDJ2Z7A7YN4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Chris Angelico]

On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing  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-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/C3L6EUY5SAMWHSDOHNQJLWXPUJ67A4AQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Sat, Jul 11, 2020 at 5:28 PM Greg Ewing 
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?)*

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico  wrote:

> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing 
> 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?)*

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Greg Ewing]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Chris Angelico]

On Sun, Jul 12, 2020 at 11:04 AM Guido van Rossum  wrote:
>
> On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico  wrote:
>>
>> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing  
>> 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-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/DT2RBMJ2BO2FG5PBWCNGID2DPYYMVQV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-12 01:32, Chris Angelico wrote:

On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing  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-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/OUT2EZB5VMWT4VGJCGF7DAWMTNJAVHRT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

On 12/07/2020 02:04, Guido van Rossum wrote:
On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico > 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
___
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/HFYHV6DKX227JT2ZR2UYLVT3N7O4JDCK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim J. Jewett]

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