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

I did make the following arguments about less indentation in https://github.com/gvanrossum/patma/issues/59 To recap: 1. Similarity to if/elif/else and try/except/finally statements in how code lines up 2. Less apparent complexity, since indentation is a visual signal for such 3.

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

Hello, On Sat, 11 Jul 2020 00:35:39 +0200 Federico Salerno wrote: [] > A few emails ago I proposed something like this (and I'm probably > only the last one to do so amongst many), but if anyone made an > argument against it I must have missed it: The PEP itself in "rejected" ideas makes an

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

On 7/10/2020 3:15 AM, Gustavo Carneiro wrote: On Fri, 10 Jul 2020 at 10:33, Glenn Linderman > wrote: On 7/10/2020 1:21 AM, Stefano Borini wrote: > Just my 2 cents, I find it kind of annoying that the whole structure > requires two levels of

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

Federico Salerno wrote: > Is there anything (bar tradition or other subjective arguments) that speaks > in favour of this, especially in light of the fact that having the same > indentation level would also solve other problems? ...if anyone made an > argument against it I must have missed it:

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

On 10/07/2020 12:33, 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

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2020-07-03 - 2020-07-10) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7530 (+10) closed 45482 (+58) total 53012 (+68) Open issues

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

On Fri, Jul 10, 2020 at 9:54 AM Michael Lee wrote: > One small question about this part of the PEP: > > > For the most commonly-matched built-in types (bool, bytearray, bytes, > dict, float, frozenset, int, list, set, str, and tuple), a single > positional sub-pattern is allowed to be passed to

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

One small question about this part of the PEP: > For the most commonly-matched built-in types (bool, bytearray, bytes, dict, float, frozenset, int, list, set, str, and tuple), a single positional sub-pattern is allowed to be passed to the call. Rather than being matched against any particular

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

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.

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

> On 10 Jul 2020, at 01:51, Jim Baker wrote: > > > On Thu, Jul 9, 2020 at 1:42 PM Eric Nieuwland > wrote: > Much of the discussion seems to focus on how to distinguish between a > variable as a provider of a value and a variable as receiver of a matched >

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

> On 10 Jul 2020, Stefano Borini wrote: > > Just my 2 cents, I find it kind of annoying that the whole structure > requires two levels of indentation to actually reach the operational > code. > This would be a first in python. > > I would prefer an option akin to if elif elif else where each

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

On Fri, 10 Jul 2020 at 12:08, 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

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

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

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

On Fri, 10 Jul 2020 at 10:33, Glenn Linderman wrote: > On 7/10/2020 1:21 AM, Stefano Borini wrote: > > Just my 2 cents, I find it kind of annoying that the whole structure > > requires two levels of indentation to actually reach the operational > > code. > > This would be a first in python. > >

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

If we are still not certain about the exact language to describe match then I would ask if the 'case' token is really required. It seems that I would prefer match expr: pattern0: block0 pattern1: block1 . else: blockdefault where the else: clause is optional.

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

On 7/10/2020 1:21 AM, Stefano Borini wrote: Just my 2 cents, I find it kind of annoying that the whole structure requires two levels of indentation to actually reach the operational code. This would be a first in python. I would prefer an option akin to if elif elif else where each block is

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

Just my 2 cents, I find it kind of annoying that the whole structure requires two levels of indentation to actually reach the operational code. This would be a first in python. I would prefer an option akin to if elif elif else where each block is only one level deep. On Wed, 8 Jul 2020 at