On Wed, May 18, 2016 at 10:15 PM, Guido van Rossum wrote:

I guess the tuple structure matching idea is fairly easy to grasp.

The attribute idea would be similar to a duck-type check, though more emphasizing data attributes. It would be nice if we could write a match that said "if it has attributes x and y, assign those to local variables p and q, and ignore other attributes". Strawman syntax could be like this:

def demo(arg): switch arg: case (x=p, y=q): print('x=', p, 'y=', q) case (a, b, *_): print('a=', a, 'b=', b) else: print('Too bad')

That the first case would match attributes and not named items seems surprising to me. That is, just by looking at it I would have expected it to match {'x': 1, 'y': 2}. This feels more in line with the way that keyword arguments work, and more consistent with the second case in that both would be matching contents of collections.

On 19 May 2016 at 14:15, Guido van Rossum wrote:

The attribute idea would be similar to a duck-type check, though more emphasizing data attributes. It would be nice if we could write a match that said "if it has attributes x and y, assign those to local variables p and q, and ignore other attributes". Strawman syntax could be like this:

def demo(arg): switch arg: case (x=p, y=q): print('x=', p, 'y=', q) case (a, b, *_): print('a=', a, 'b=', b) else: print('Too bad')

For the destructuring assignment by attribute, I'd suggest the "value as name" idiom, since it's not quite a normal assignment, as well as a leading "." to more readily differentiate it from iterable unpacking: def demo(arg): switch arg: case (.x as p, .y as q): print('x=', p, 'y=', q) case (a, b, *_): print('a=', a, 'b=', b) else: print('Too bad') Whether to allow ".x" as a shorthand for ".x as x" would be an open question.

Someone else can try to fit simple value equality, set membership, isinstance, and guards into that same syntax.

For these, I'd guess the most flexible option would be to allow the switch expression to be bound to a name: switch expr as arg: case arg == value: ... case lower_bound <= arg <= upper_bound: ... case arg in container: ... Similar to with statement and for loops, this wouldn't create a new scope, it would just bind the name in the current scope (and hence the value would remain available after the switch statement ends) If we went down that path, then the "assign if you can, execute this case if you succeed" options would presumably need an explicit prefix to indicate they're not normal expressions, perhaps something like "?=": switch expr as arg: case ?= (.x as p, .y as q): print('x=', p, 'y=', q) case ?= (a, b, *_): print('a=', a, 'b=', b) case arg == value: ... case lower_bound <= arg <= upper_bound: ... case arg in container: ... else: print('Too bad') Which would then have the further implication that it might also make sense to support attribute unpacking as the LHS of normal assignment statements: (.x as p, .y as q) = expr In a similar vein, item unpacking might look like: (["x"] as p, ["y"] as q) = expr And unpacking different structures might look like: switch expr: case ?= (.x as x, .y as y): ... # x/y as attributes case ?= (["x"] as x, ["y"] as y): ... # x/y as mapping case ?= (x, y): ... # 2-tuple (or other iterable) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

I think there should be different syntaxes for matching equality and binding patterns, and definitely different syntax for singular and plural cases. Let's try this: - Equality: `case 5:` - Conditional: `case if predicate(obj):` - Pattern-matching: `case as [a, b, *_]:` `case as Point(x, y):` Slightly-more-explicit checks, instead of simply `case 5:`. - `case == 5:` - `case is _sentinel:` - `case is None:` - `case < 6:` - `case in (1,2,3):` - `case in range(2, 5):` - `case in int:` The above uses an implicit object and is very different from how Python usually works. Though I think it's mentally consistent (as in, no contradictions), it's not an extrapolation of current syntax, and might go against "explicit self". It isn't necessary, though: require `case 5` and `case if obj == 5:`. I prefer `case == 5` and `case is 5`, though, even if that's not how other languages do it. The last one treats a type as a collection of its instances, which I just like. (I also like `SubClass < BaseClass`.) On Thu, May 19, 2016 at 4:20 AM, Greg Ewing wrote:

If we want this feature, it seems like we will need to explicitly mark either names to be bound or expressions to be evaluated and matched against.

Possible pre-fix markers: case as Point(zero, =y): case as Point(zero, !y): case as Point(zero, $y): case as Point(zero, &y): case as Point(zero, ^y): case as Point(zero, :y): Possible post-fix markers: case as Point(zero, y=): case as Point(zero, y!): case as Point(zero, y:): I think the colon won't be ambiguous in dict displays (it's only a marker if one side of the colon is missing), but it might complicate the parser. It'd be ambiguous in slicing, but I don't see slice-matching being a thing. (My favorite is probably `&y`, for a bad reason: it's very C-like. That'd confuse C programmers when `&` doesn't work anywhere else and `*` won't work at all.)

If you wanted the second case to only match the tuple, you could write

case tuple(a, b, *_):

Slightly naughty. The tuple constructor only takes one argument. On Thu, May 19, 2016 at 12:15 AM, Guido van Rossum wrote:

A few things that might be interesting to explore:

I'll try out my syntax ideas on these.

- match by value or set of values (like those PEPs)

`case == 1:` `case in (1, 2, 3):`

- match by type (isinstance() checks)

`case in int:` `case if isinstance(obj, int):` `case if type(obj) == tuple:`

- match on tuple structure, including nesting and * unpacking (essentially, try a series of destructuring assignments until one works)

`case in tuple as (first, *middle, last):` `case if isinstance(obj, tuple) as (first, *middle, last):` `case if type(obj) == tuple as (first, *middle, last):`

- match on dict structure? (extension of destructuring to dicts)

I think it makes no sense to bind the keys to names, because they'd just be chosen arbitrarily (unless it's an OrderedDict), so let's say keys are evaluated and values are (by default) names to bind. Let `**_` mean "other items". `case as {'foo': x, 'bar': y, **_}:` `case as {key0: val0, key1: val1}: # Binds val0 and val1.` `case as {'foo': foo_val, var_holding_bar: bar_val, **_}:` ^ Ew. I'd like names-to-bind to require special syntax. `case as dict(foo=foo_val, **{var_holding_bar: bar_val}, **_):` If we had an OrderedDict syntax, binding keys makes more sense. case as [k0: v0, **_, klast: vlast]: P.S.: If `**_` is allowed in matching, it should be allowed in unpacking assignment. {'foo': x, 'bar': y, **_} = d

- match on instance variables or attributes by name?

One of the following: `case as object(foo=x, bar=y):` `case as Object(foo=x, bar=y):` `case as SpecialAttrMatchingThing(foo=x, bar=y):` `SpecialAttrMatchingThing` objects would be special in the match system.

- match on generalized condition (predicate)?

`case <= 4:` `case if is_something(the_obj):` `case as Point(x, y) if x == y:` `case if len(the_obj) < 5 as [first, second, *_] if isinstance(first, int):` == Matching user classes == What about using pickle dunders for this? In particular, `MyClass.__getnewargs__` and `MyClass.__getnewargs_ex__`. Pickling is kind of related to pattern matching. Note that the classes don't have to be immutable to be matchable. When matching `p` to `Point(x, y)`, the match system calls `Point.__getnewargs__(p)` (NOT `p.__getnewargs__`, thus allowing for some subclass matching). The result is matched against a two-tuple, and finally bound. # def match_constructor(obj, cls): if not isinstance(obj, cls): raise FailedMatch try: m = cls.__getnewargs_ex__ except AttributeError: pass else: args, kwargs = m(obj) # Even for subclasses. return args, kwargs try: m = cls.__getnewargs__ except AttributeError: raise FailedMatch args = m(obj) return args, {} # Back in the case: try: (x, y), [] = match_constructor(p, Point) except ValueError: raise FailedMatch run_block() The problem is that these functions return (args, kwargs), and optional args and pos_or_kw_params mess things up. Point(x, y) Point(x, y=y) # How can match system know that all of the following are valid patterns? Something(x) Something(x, y) Something(*args, **kwargs) Solution 1: Additional args to the pickle methods (or make a new method which could sometimes be used for pickling): - nargs: Number of args. An int, or a integer range (for `*args`). A `range` doesn't allow unbounded, so use `slice(min_nargs, None)`, `(min_nargs, ...)`, or `(min_nargs, None)`. - kws: Keywords. To represent **kwargs, either add another arg or pass `...` or `None` as a keyword. Solution 2: After receiving (args, kwargs) from the class, inspect the signature of the class constructor and just figure out how it works. == Additional Resources == * MacroPy implements case classes, which are similar to what Haskell uses for pattern matching on constructors. I'm not sure that it lends insight to the `Point(x, y)` case, because MacroPy doesn't have pattern matching, but maybe someone else would. https://github.com/lihaoyi/macropy#case-classes * "Pattern matching in Python" (2009) An attempt at making a matching thing. https://monkey.org/~marius/pattern-matching-in-python.html * PEP 275 -- Switching on Multiple Values https://www.python.org/dev/peps/pep-0275/ * PEP 3103 -- A Switch/Case Statement https://www.python.org/dev/peps/pep-3103/

On Thu, May 19, 2016 at 10:38 PM Nick Coghlan wrote:

On 19 May 2016 at 14:15, Guido van Rossum wrote:

...

The attribute idea would be similar to a duck-type check, though more emphasizing data attributes. It would be nice if we could write a match that said "if it has attributes x and y, assign those to local variables p and q, and ignore other attributes".

If we went down that path, then the "assign if you can, execute this case if you succeed" options would presumably need an explicit prefix to indicate they're not normal expressions, perhaps something like "?=":

switch expr as arg: case ?= (.x as p, .y as q): print('x=', p, 'y=', q)

If you don't mind adding a new operator, then an easier way to handle several of these situations would be to make ``?=`` an assignment expression that evaluates to True/False whether the assignment succeeded: def foo(obj): return a ?= obj.a Could be equivalent to: def foo(obj): try: a = obj.a except Exception: return False else: return True The use-cases of are somewhat overlapping with the idea of an inline try/except as in PEP 463 (https://www.python.org/dev/peps/pep-0463/). Which would then have the further implication that it might also make

sense to support attribute unpacking as the LHS of normal assignment statements:

(.x as p, .y as q) = expr

The ``as`` syntax flips the familiar variable-on-the-left and makes this one tough for me to read. I'd rather force a little repetition: o = expr p, q = o.x, o.y Using a temporary variable like ``o`` makes it even fewer characters than the proposed parens and ``as`` keyword.

On 20 May 2016 at 17:45, Ryan Gonzalez wrote:

On Fri, May 20, 2016 at 5:48 AM, Franklin? Lee wrote:

...

I think there should be different syntaxes for matching equality and binding patterns, and definitely different syntax for singular and plural cases.

Let's try this: - Equality: `case 5:` - Conditional: `case if predicate(obj):` - Pattern-matching: `case as [a, b, *_]:` `case as Point(x, y):`

Slightly-more-explicit checks, instead of simply `case 5:`. - `case == 5:` - `case is _sentinel:` - `case is None:` - `case < 6:` - `case in (1,2,3):` - `case in range(2, 5):` - `case in int:`

I personally really like the equality, conditional, and pattern-matching syntax you showed; it looks the most Pythonic IMO.

Agreed.

However, the more explicit checks are a little overkill and feel like too much special-casing. I don't know of any languages that go so far as to allow stuff like `case < 6`; usually, there would instead be some syntax to assign the initial object to an intermediate variable, that way you can just use it with an `if` predicate.

Also agreed. It seems that switch expr as name case if name is _sentinel: do_stuff() would be a reasonable syntax for naming the switch expression - although just giving it a name before using it in the switch is probably just as reasonable: name = expr switch name: case if name is _sentinel: do_stuff() BTW, there's also a semantic question - if multiple cases match, would only one (presumably the first) or all of them be executed? I'm sure this was discussed to death during the discussions on PEPs 3103 and 275, but I don't have the time or inclination to re-read those now, so I'll just leave the question open here for someone else to do the research... Paul

Agreed, if we want to support the structural pattern matching as seen in Haskell, Rust, or Scala, we should do the following: - Match in sequence against the provided cases. Cases should support optional guards (`if` clause) - Follow only one case - no fall through, no need to `break` - Raise a match error if the match is not exhaustive; an `else` clause is fine for exhaustion Using the typical switch pattern seen in C or Java is already idiomatically addressed in Python through dispatching through a dict. This type of matching is different. On Fri, May 20, 2016 at 11:47 AM, Guido van Rossum wrote:

It's definitely going to be "try cases in order until one matches".

On Fri, May 20, 2016 at 10:45 AM, Paul Moore wrote:

...

On 20 May 2016 at 17:45, Ryan Gonzalez wrote:

...

On Fri, May 20, 2016 at 5:48 AM, Franklin? Lee wrote:

...

I think there should be different syntaxes for matching equality and binding patterns, and definitely different syntax for singular and plural cases.

Let's try this: - Equality: `case 5:` - Conditional: `case if predicate(obj):` - Pattern-matching: `case as [a, b, *_]:` `case as Point(x, y):`

Slightly-more-explicit checks, instead of simply `case 5:`. - `case == 5:` - `case is _sentinel:` - `case is None:` - `case < 6:` - `case in (1,2,3):` - `case in range(2, 5):` - `case in int:`

I personally really like the equality, conditional, and pattern-matching syntax you showed; it looks the most Pythonic IMO.

Agreed.

...

However, the more explicit checks are a little overkill and feel like too much special-casing. I don't know of any languages that go so far as to allow stuff like `case < 6`; usually, there would instead be some syntax to assign the initial object to an intermediate variable, that way you can just use it with an `if` predicate.

Also agreed. It seems that

switch expr as name case if name is _sentinel: do_stuff()

would be a reasonable syntax for naming the switch expression - although just giving it a name before using it in the switch is probably just as reasonable:

name = expr switch name: case if name is _sentinel: do_stuff()

BTW, there's also a semantic question - if multiple cases match, would only one (presumably the first) or all of them be executed? I'm sure this was discussed to death during the discussions on PEPs 3103 and 275, but I don't have the time or inclination to re-read those now, so I'll just leave the question open here for someone else to do the research...

Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, May 20, 2016, at 15:25, Jim Baker wrote:

Agreed, if we want to support the structural pattern matching as seen in Haskell, Rust, or Scala, we should do the following:

- Raise a match error if the match is not exhaustive; an `else` clause is fine for exhaustion

This is required because the analogous constructs in those languages are expressions that return a value, and there's no reason to require it for a python construct which is a statement.

On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno wrote:

I still fail to see what justifies violating The One Obvious Way to Do It which uses an if/elif sequence so blatantly beyond the feeble "Yet, some kind of switch statement is found in many languages and it is not unreasonable to expect that its addition to Python will allow us to write up certain code more cleanly and efficiently than before." in the rejected PEP.

It is not like omitting the object reference name on the conditional expression (and therefore, a condition expression that is tied to one object) is more readable at all.

But them, it is the BDLF cming with the proposal - I am just this Python develoepr teacher, that just last Wednesday was saying something along on a crash course: "We don need switch/case because it is just a special case of an if/elif sequence, that was meaningful when C compilers did not had resources to optimize that themselves".

I argue no further, if people still see this as desirable.Ths is just my plain Python user "-1" on python-ideas.

Honestly I'm not at all convinced either! If it was easy to do all this with a sequence of if/elif clauses we wouldn't need it. The problem is that there are some types of matches that aren't so easy to write that way, e.g. combining an attempted tuple unpack with a guard, or "instance unpack" (check whether specific attributes exist) possibly combined with a guard. (The tricky thing is that the guard expression often needs to reference to the result of the unpacking.) It might become yet more interesting when combining the unpack syntax with type annotations, so you could check e.g. whether there's an x attribute that's a float and a y attribute that's a string. But it's about the most speculative piece of language design I've contemplated in a long time... -- --Guido van Rossum (python.org/~guido)

On Mon, May 23, 2016 at 3:49 PM, Michael Selik wrote:

On Mon, May 23, 2016 at 3:58 PM Guido van Rossum wrote:

...

On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno wrote:

...

I still fail to see what justifies violating The One Obvious Way to Do It which uses an if/elif sequence

Honestly I'm not at all convinced either! If it was easy to do all this with a sequence of if/elif clauses we wouldn't need it. The problem is that there are some types of matches that aren't so easy to write that way, e.g. combining an attempted tuple unpack with a guard, or "instance unpack" (check whether specific attributes exist) possibly combined with a guard. (The tricky thing is that the guard expression often needs to reference to the result of the unpacking.)

Wouldn't an exception-catching expression (PEP 463) enable most of what you want with the existing if/elif/else chain?

def demo(arg): if ((arg.x, arg.y) except AttributeError: False): print('x=', arg.x, 'y=', arg.y) elif ((arg[0], arg[1]) except IndexError: False): a, b, *_ = arg print('a=', a, 'b=', b) else: print('Too bad')

To get everything you want, we could have an exception-catching assignment expression. While a plain ``=`` assignment would be problematic as an expression due to the common ``==`` typographical error, a less error-prone operator might be OK. I'd suggested ``?=`` earlier in the thread, but perhaps I didn't write out a good example at that time. Here's one that's closer to the original demo example.

def demo(arg): if p, q ?= arg.x, arg.y: print('x=', p, 'y=', q) elif a, b, *_ ?= arg: print('a=', a, 'b=', b) else: print('Too bad')

I figure it's better to solve the category of problems -- exception-catching expressions -- rather than the single problem of catching exceptions in an if/elif/else chain. Or do you think this is too much temptation for unreadable code golf?

People are likely either going to put in exceptions that don't catch enough (e.g. IndexError isn't the only exception that example can throw) or, overreacting to that problm, that catch everything ("except Exception:" is an anti-pattern that's hard to fight). Plus there's the redundancy that you showed. -- --Guido van Rossum (python.org/~guido)

No, what I'm saying is that seeing it as sugar for exception handing is the wrong way to look at it. On Mon, May 23, 2016 at 4:52 PM, Michael Selik wrote:

On Mon, May 23, 2016 at 7:13 PM Guido van Rossum wrote:

...

On Mon, May 23, 2016 at 3:49 PM, Michael Selik wrote:

...

On Mon, May 23, 2016 at 3:58 PM Guido van Rossum wrote:

...

On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno wrote:

...

I still fail to see what justifies violating The One Obvious Way to Do It which uses an if/elif sequence

Honestly I'm not at all convinced either! If it was easy to do all this with a sequence of if/elif clauses we wouldn't need it. The problem is that there are some types of matches that aren't so easy to write that way, e.g. combining an attempted tuple unpack with a guard, or "instance unpack" (check whether specific attributes exist) possibly combined with a guard. (The tricky thing is that the guard expression often needs to reference to the result of the unpacking.)

I figure it's better to solve the category of problems -- exception-catching expressions -- rather than the single problem of catching exceptions in an if/elif/else chain.

People are likely either going to put in exceptions that don't catch enough (e.g. IndexError isn't the only exception that example can throw) or, overreacting to that problm, that catch everything ("except Exception:" is an anti-pattern that's hard to fight).

It sounds like the justification for a switch/match syntax is to provide a special situation where generic Exception-catching assignment expressions are acceptable, because they're useful in a long elif chain but too dangerous for widespread use.

Clearly it's beneficial enough to have appeared in other languages. However, languages like Haskell have already accepted the danger of assignment (and more) being an expression. Is there a language that makes the expression/statement distinction that has as powerful a matching syntax?

-- --Guido van Rossum (python.org/~guido)

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

On Mon, May 23, 2016 at 8:23 PM Guido van Rossum wrote:

...

No, what I'm saying is that seeing it as sugar for exception handing is the wrong way to look at it.

Ok, let me refocus on the idea of assign-if-you-can during matching, not just sugar for try/except.

The matching features of equality, inequality, predicates, and subtype are already available via if/elif. The matching features of destructuring, assignment, and post-assignment guards need new syntax. The other proposals in this thread suggest a new keyword or keyword pair like switch/case. Instead, why not extend if/elif with a new operator?

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

A major advantage to merging these new matching features with the existing if/elif is that refactoring gets much easier. One could insert a single elif block near the top of the chain using the new assign-if-you-can operator/keyword, without needing to change any of the existing elif statements.

Otherwise, I could imagine someone waffling back and forth between switch/case and if/elif as they add and remove cases. What would be the style recommendation if you have 5 boring cases that are all easy to read via if/elif?

The disadvantage would be that the new syntax wouldn't stand out as much as it would with, say, switch/case, and someone might not notice its usage. I think a good choice of operator/keyword mitigates this. A keyword like ``as`` would stand out due to syntax highlighting. An operator like ``?=`` looks different enough and many similar-looking operators, like ``/=`` would be illegal.

Operator precedence would affect the beauty of the code. Giving ``?=`` the same precedence as ``==`` seems best for post-assignment guards.

This idea has some clear advantages -- it's unambiguous about the order of matching, and combines clearly with existing conditions. It also seems like it would support "recursive" matching nicely, by allowing you to chain additional unpacking operators. ("Recursive" because IIUC that's what Haskell calls matches inside matches -- similar to nested tuple unpackings like (a, (b, c)) = in Python.) The trick is to find a good syntax for the conditional assignment; using ? has been rejected by this group in the past for other conditionalisms. -- --Guido van Rossum (python.org/~guido)

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

I'm unenthusiastic about this -- the above looks like an unreadable mess to me. Some other worries: * It appears that this would have to work by means of exception-catching in the rhs, so it's really a disguised form of the except: expression proposal; is that intentional? * It could also be abused to get an assigment-in- expression anywhere you wanted. Such things have been rejected before; are we changing our mind on that? * THere would be no hope of checking for coverage of all cases in a static checker. I feel like we've wandered a long way from the idea we started with, which is something to facilitate a Haskell-like case-analysis style of programming, and ended up with something much looser that tries to be all things to everyone. -- Greg

On 24.05.2016 08:08, Greg Ewing wrote:

...

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

I'm unenthusiastic about this -- the above looks like an unreadable mess to me.

Seconded. It would be more readable to make the assignment explicit: if (p, q = arg.x, arg.y): ... but even then I find this error prone. Just think of the common typo of writing "if x = 1: ..." instead of "if x == 1: ...". This version p, q = arg.x, arg.y if (p, q): ... is just a bit more verbose, but comes without all the problems of having to allow implicit assignment-in-expression everywhere. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 24 2016)

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

Ok, let me refocus on the idea of assign-if-you-can during matching, not just sugar for try/except.

The matching features of equality, inequality, predicates, and subtype are already available via if/elif. The matching features of destructuring, assignment, and post-assignment guards need new syntax. The other

On Tue, May 24, 2016 at 6:43 AM, Guido van Rossum wrote: proposals

...

in this thread suggest a new keyword or keyword pair like switch/case. Instead, why not extend if/elif with a new operator?

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

[...] This idea has some clear advantages -- it's unambiguous about the order of matching, and combines clearly with existing conditions. It also seems like it would support "recursive" matching nicely, by allowing you to chain additional unpacking operators. ("Recursive" because IIUC that's what Haskell calls matches inside matches -- similar to nested tuple unpackings like (a, (b, c)) = in Python.)

The trick is to find a good syntax for the conditional assignment; using ? has been rejected by this group in the past for other conditionalisms.

Yeah, and indeed it's not obvious how to draw the line between whether the conditional assignment should return a truth value or raise an exception, as I think Greg was already implying. For instance, what would `a ?= data[0]` do, if data[0] raises, say, a TypeError. Should it be caught or be raised? Anyway, maybe it is possible to draw that line in a reasonable way. So here's a ​nother syntax : Introduce a ​new ​ keyword `given`, which ​could be used as a prefix operator with roughly the following properties given a ​ ​ # True if the name a is bound to something given b.c ​ ​ # roughly equivalent to hasattr(b, 'c') given a, b.c ​ ​ # same as (given a and given b.c) given d, e = a, b.c ​ ​ # like `given a, b.c` but with added assignment Then one could do ( ​expanding on the above demo example) def demo(arg): if given p, q = arg.x, arg.y: # do something elif given x = arg.x and isinstance(x, int): # do somet​​hing elif given a, b, *_ = arg: # do somet​h​ing elif isinstance(arg, Mapping): # do something ​# Or something like this: ​ ​ def demo2(arg):​ ​ global importan​t_value ​ ​ ​ if not given important_value: important_value = compute_important_value() ​-- Koos​ ​PS. I like seeing the word "brainstorm" used here. I'm not sure if I've seen that here before. I think that means that we try to see the good parts of the presented ideas and send further ideas and thoughts to see if we can find something useful -- even if the presented ideas are not yet optimal. (Of course that does not mean that the ideas should not be presented clearly!) Anyway, in the end, if nothing is found, it is easy to just drop the whole concept. ​

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, May 24, 2016 at 2:08 AM Greg Ewing wrote:

...

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

I'm unenthusiastic about this -- the above looks like an unreadable mess to me.

Which is unreadable: ``if/elif`` keywords or ``?=`` operator? If it's the latter, please don't get hung up on that, as I intended that as a placeholder for whatever operator or keyword is best. My main point is that switch/case/matching is semantically identical to if/elif, so why use something different?

Some other worries:

* It appears that this would have to work by means of exception-catching in the rhs, so it's really a disguised form of the except: expression proposal; is that intentional?

No. The exception-catching expression is not meant to be available in any other context. However, exception-catching is an essential feature to matching via destructuring. I believe it's unavoidable, though *which* exceptions are suppressed could be made more clear. * It could also be abused to get an assigment-in-

expression anywhere you wanted. Such things have been rejected before; are we changing our mind on that?

No, using the assign-if-can operator would be syntax error outside of an if/elif, the reverse of how an assign operator is a syntax error inside an if/elif. * THere would be no hope of checking for coverage

of all cases in a static checker.

I believe you, though the logic isn't clear to me. Could you explain why?

I feel like we've wandered a long way from the idea we started with, which is something to facilitate a Haskell-like case-analysis style of programming, and ended up with something much looser that tries to be all things to everyone.

That was not my intention. If the assign-if-can operation is only available in an if/elif statement, I think it's exactly Haskell-like case-analysis and nothing more. Did I miss something?

On 24 May 2016 at 14:31, Michael Selik wrote:

On Tue, May 24, 2016 at 2:08 AM Greg Ewing wrote:

...

...

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

I'm unenthusiastic about this -- the above looks like an unreadable mess to me.

Which is unreadable: ``if/elif`` keywords or ``?=`` operator? If it's the latter, please don't get hung up on that, as I intended that as a placeholder for whatever operator or keyword is best. My main point is that switch/case/matching is semantically identical to if/elif, so why use something different?

For me, it's the use of operators (punctuation) plus the fact that the overall layout doesn't in any way imply to me "I'm looking at *this* expression. Let's try a sequence of matches..." The key distinguishing feature for me of a switch/match statement is that it organises the "flow" of the statement differently from if/elif. The if/elif chain says "try this, then that, now something else". There's no implication that the tests are all looking at the same subject - to spot that, you need to be able to see (from the layout of the tests) the actual subject item on each line, and the ?= operator syntax obscures that because "arg" is used differently in each test. With a switch statement, however, the subject is stated once, at the top of the statement. The checks are then listed one after the other, and they are all by definition checks against the subject expression. And in fact, for me that's the distinguishing feature of a switch statement - that it's a series of tests against a single implied subject. That's also (I suspect) why it's hard to come up with a good syntax for tests - Python doesn't really do "implied subjects" anywhere else (explicit is better than implicit and all that). IMO, "Series of tests against a single expression" is a common enough pattern to be worth exploring in spite of the fact that it runs counter to EIBTI. But you may need to be Dutch to understand why :-) Paul

What about making it a function ? Pattern matching is complex, it can be like a mini language inside the language, just like regex. To match text we do: import re re.match('pattern', 'string') We could do the same for matching structures: from inspect import match def do(stuff): m = match(stuff): # m implements __call__ if m('whatever mini language you like'): return foo if m('again'): return m.thing_your_extracted Pros: - no need for a new syntax - very explicit - use well know constructs - we can easily start experimenting with the matching language in a lib in Pypy Cons: - much more verbose; - debugging your mini language and handling error is not as good; Le 24/05/2016 16:35, Paul Moore a écrit :

On 24 May 2016 at 14:31, Michael Selik wrote:

...

On Tue, May 24, 2016 at 2:08 AM Greg Ewing wrote:

...

...

On Mon, May 23, 2016 at 7:57 PM, Michael Selik wrote:

...

def demo(arg): if p, q ?= arg.x, arg.y: # dict structure elif x ?= arg.x and isinstance(x, int) # assignment + guard elif a, b, *_ ?= arg: # tuple structure elif isinstance(arg, Mapping): # nothing new here

I'm unenthusiastic about this -- the above looks like an unreadable mess to me.

Which is unreadable: ``if/elif`` keywords or ``?=`` operator? If it's the latter, please don't get hung up on that, as I intended that as a placeholder for whatever operator or keyword is best. My main point is that switch/case/matching is semantically identical to if/elif, so why use something different?

For me, it's the use of operators (punctuation) plus the fact that the overall layout doesn't in any way imply to me "I'm looking at *this* expression. Let's try a sequence of matches..."

The key distinguishing feature for me of a switch/match statement is that it organises the "flow" of the statement differently from if/elif. The if/elif chain says "try this, then that, now something else". There's no implication that the tests are all looking at the same subject - to spot that, you need to be able to see (from the layout of the tests) the actual subject item on each line, and the ?= operator syntax obscures that because "arg" is used differently in each test.

With a switch statement, however, the subject is stated once, at the top of the statement. The checks are then listed one after the other, and they are all by definition checks against the subject expression. And in fact, for me that's the distinguishing feature of a switch statement - that it's a series of tests against a single implied subject. That's also (I suspect) why it's hard to come up with a good syntax for tests - Python doesn't really do "implied subjects" anywhere else (explicit is better than implicit and all that).

IMO, "Series of tests against a single expression" is a common enough pattern to be worth exploring in spite of the fact that it runs counter to EIBTI. But you may need to be Dutch to understand why :-)

Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Structural pattern matching should address the following, somewhat similar
to regex pattern matching:

1. Patterns are quoted. This can be implicitly done, because of built-in
syntactic support; or one is supplying the pattern to a library using
regular Python quoting.

2. Patterns should support bind variables for the unpacking. In languages
like Scala, this is very natural to do, with bop, v1, v2 lexically scoped
to the RHS of =>.

```scala
case Binary(bop @ (Lt|Le|Gt|Ge), v1, v2) if isValue(v1) && isValue(v2) =>
   doreturn(B(inequalityVal(bop, v1, v2)) )
```

This is an example from an interpreter used in a lab exercise in a class I
teach, with patterns against ASTs. The ASTs are themselves defined in terms
of Scala's case classes, which are more or less equivalent to namedtuples
in Python.

Clearly the scoping of bind variables can be emulated by the match object,
much as we do in regexes, at the cost of some minor overhead.

3. Some protocol to connect together objects like tuples, namedtuples, and
arbitrary classes with the matching. In Scala, this is called unapply, and
given that Scala has similar object-oriented aspects that are similar to
Python in making life more difficult ;), when compared to Haskell's
comparatively simple rules, it's probably close to what we need to do for
__match__ or something like that.

The challenge is making this work together, especially distinguishing
patterns from bind variables. Haskell makes it easy by a requirement that
algebraic types have constructors which start with an upper case letter.
Scala can do simple scope analysis of names to determine if it's a case
class or a bind variable. For Python, presumably more syntax is necessary
in the pattern specifier. Maybe something like the following, which seems
unambiguous, possibly not so ugly:

```python
case Binary(bop @ (Lt|Le|Gt|Ge), v1@, v2@) if isValue(v1) and isValue(v2):
   # bop, v1, v2 are lexically scoped here
```

Am I missing anything? It seems to me that one can do structural pattern
matching as a library (do obvious changes to above); although having it
supported with specific syntax might make it much nicer.

- Jim



On Tue, May 24, 2016 at 11:42 AM, Koos Zevenhoven  wrote:

> On Tue, May 24, 2016 at 5:59 PM, Michel Desmoulin
>  wrote:
> > What about making it a function ?
> >
> > Pattern matching is complex, it can be like a mini language inside the
> > language, just like regex.
> >
> > To match text we do:
> >
> > import re
> > re.match('pattern', 'string')
> >
> > We could do the same for matching structures:
> >
> > from inspect import match
> >
> > def do(stuff):
> >     m = match(stuff): # m implements __call__
> >     if m('whatever mini language you like'):
> >         return foo
> >     if m('again'):
> >         return m.thing_your_extracted
> >
>
> Or with methods:
>
> m = match(stuff)
> if m.by_type(SomeType):
>     # handle SomeType
> elif m.by_attrs('x', 'y'):
>     # do things with stuff.x and stuff.y
> elif m.by_len(3):
>     x,y,z = stuff
>     # do things with x, y, z
>
> > Pros:
> >
> > - no need for a new syntax
> > - very explicit
> > - use well know constructs
> > - we can easily start experimenting with the matching language in a lib
> > in Pypy
> + can be extended easily
>
> >
> > Cons:
> >
> > - much more verbose;
> > - debugging your mini language and handling error is not as good;
> + probably slower
> + need to separately get the desired attributes/elements after matching.
>
> -- Koos
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Paul Moore writes:

With a switch statement, however, the subject is stated once, at the top of the statement. The checks are then listed one after the other, and they are all by definition checks against the subject expression. And in fact, for me that's the distinguishing feature of a switch statement

+1 That may also make some optimizations easier to spot. I'm also -1 on the ?= syntax, which reads "maybe assign" to me, but that covers way too much ground (and in particular has been proposed for "null-propagation" in the recent past). I admit I'm not in love with the "switch/case" syntax for the kind of matching intended here, as C's switch is way too burned into my thinking. I think it's gone right through the EEPROM silicon into the plastic case[sic, just can't get away from those preexisting "case"es!] How about for <thing>: try <matcher>: pass try <matcher>: pass Look Ma! No new keywords! Yeah, I know, "for" and "try" both have very strong connotations in Python already, so this may be a "not even the Dutch could like it" automatic-parser-only syntax. Steve

On Tue, May 24, 2016 at 7:03 PM Greg Ewing wrote:

Michael Selik wrote:

...

My main point is that switch/case/matching is semantically identical to if/elif, so why use something different?

But then you say

...

No, using the assign-if-can operator would be syntax error outside of an if/elif, the reverse of how an assign operator is a syntax error inside an if/elif.

So what you're proposing is *not* semantically equivalent to composing the existing if/elif with a new pattern matching assignment, which means re-using the existing keywords for it is misleading.

Perhaps I didn't explain my proposal correctly. I spent about 3 hours this evening writing out a more thorough proof of the semantic equivalence. As I did so, toying with different syntaxes, I realized that it might be better to break this problem apart and solve a few subproblems first. The first problem to solve is how to write a destructuring bind for more than just sequences. Once we're happy with that, it'll be easier to discuss pattern matching. # Iterable-destructuring bind (a.k.a unpacking) (a, b, *rest) = sequence # Subscriptable-destructuring bind {'x': p, 'y': q} = mapping {0: p, 42: q, **rest} = indexable # Attribute-destructuring bind (a few awkward ideas) (.x: p, .y: q) = obj (x=p, y=q) = obj Or would you call that "object-destructuring"? No clue what the best name is here. I think Clojure side-steps attributes and only provides destructuring sequences and mappings. If you want to do pattern matching on a more complex type, you must provide essentially a conversion from that type to a mapping.

The exception-catching expression is not meant to be available in

...

any other context. However, exception-catching is an essential feature to matching via destructuring. I believe it's unavoidable, though *which* exceptions are suppressed could be made more clear.

my assumption was that there was nothing special about the right hand side, so the implementation would have to just evaluate all of it and catch any AttribteErrors, KeyErrors, IndexErrors, etc. emanating from it, which is much looser and prone to catching too much.

But if the right hand side is special, all bets are off and you'll have to explain exactly what would be allowed and how to interpret it.

I agree that catching all exceptions during the assign-if-can (via if/elif or switch/case) might be too error-prone. Whether it's the LHS of ``as`` or the RHS of ``?=``, it would help to restrict the kind of exceptions handled/suppressed as a failed match. However, I fail to see why ``case ... as ...`` would be restrictive and ``if ... ?= ...`` would not. They could have the same semantics, catching either a specific set of exceptions or all/most exceptions.

On 25 May 2016 at 15:11, Chris Angelico wrote:

On Wed, May 25, 2016 at 3:03 PM, Stephen J. Turnbull wrote:

...

How about

for <thing>: try <matcher>: pass try <matcher>: pass

Look Ma! No new keywords! Yeah, I know, "for" and "try" both have very strong connotations in Python already, so this may be a "not even the Dutch could like it" automatic-parser-only syntax.

I'd much prefer a different keyword instead of 'for'. If 'with' hadn't been used, that would be a better choice. Maybe 'using'... or 'switch'. But without iteration, 'for' is going to be very confusing.

As a variant on Guido's original switch/case idea: given EXPR [as TARGET]: case MATCH_PATTERN [as TARGET] [and CONDITION]: ... case MATCH_PATTERN [as TARGET] [and CONDITION]: ... case if CONDITION: ... case MATCH_PATTERN [as TARGET]: ... else: ... Using the running demo: def demo(arg): given arg: case x, y, *_: # Tuple matching (implicit name binding) ... case (.x, .y) as p, q: # Attribute matching ... case (["x"], ["y"]) as p, q: # Item matching ... case (.x) as p and isinstance(p, int): # Match + condition ... case if isinstance(arg, int): # Condition only ... else: # Default ... The other key change there is introducing "as" to the individual cases in order to be able to separate the match pattern definition from the local name binding. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 25 May 2016 at 15:33, Michael Selik wrote:

On Tue, May 24, 2016 at 7:03 PM Greg Ewing wrote:

...

But if the right hand side is special, all bets are off and you'll have to explain exactly what would be allowed and how to interpret it.

I agree that catching all exceptions during the assign-if-can (via if/elif or switch/case) might be too error-prone. Whether it's the LHS of ``as`` or the RHS of ``?=``, it would help to restrict the kind of exceptions handled/suppressed as a failed match. However, I fail to see why ``case ... as ...`` would be restrictive and ``if ... ?= ...`` would not. They could have the same semantics, catching either a specific set of exceptions or all/most exceptions.

Having the RHS of an assignment operation be syntactically restricted isn't something Python has ever done before, while the LHS is already heavily restricted (since it describes name binding targets rather than normal expressions for evaluation). The syntactic restrictions then mean evaluation order can be controlled to ensure any exception handles only cover the desired step in the process (e.g. a particular key lookup), rather than the evaluation of arbitrary subexpressions. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, May 25, 2016 at 2:26 AM Greg Ewing wrote:

My feeling is that the patterns should look like constructors. The archetypal constructor for a mapping object is the dict display, so a pattern that matches a mapping having particular keys would be

case {"x": p, "y": q}:

This is starting to look really good to me. But if that's valid in a case statement, why not in a regular assignment? (a, b, *rest) = sequence {'x': p, 'y': q, **rest} = mapping

On 25 May 2016 at 16:35, Michael Selik wrote:

On Wed, May 25, 2016 at 2:26 AM Greg Ewing wrote:

...

My feeling is that the patterns should look like constructors. The archetypal constructor for a mapping object is the dict display, so a pattern that matches a mapping having particular keys would be

case {"x": p, "y": q}:

This is starting to look really good to me. But if that's valid in a case statement, why not in a regular assignment?

(a, b, *rest) = sequence {'x': p, 'y': q, **rest} = mapping

Aye, I'm warming to that as a syntax for item unpacking (although I'm not sold on the "**rest" notation, since that entails doing something like "{k: v for k, v in obj.items() if k not in explicit_keys}" to populate it, further elevating "items()" towards the status of being a protocol method without double-underscores) I also agree with the principle that any prospective structural pattern matching statement should align with assignment target notation. Unfortunately, we don't have anything like dictionary displays to inform possible structures for an implied getattribute as part of assignment to a particular target. The option I dislike least so far is : (p=.x, q=.y) = obj # Attribute unpacking Which is clearly distinct from: (p, q) = obj # Iterable unpacking {0: p, 1: q} = obj # Item unpacking {'x': p, 'y': q} = obj # Item unpacking However, at this point we've strayed a *long* way from the ideal of "executable pseudocode" :( It would be slightly more readable if the new unpacking options used "from" as their assignment keyword rather than the traditional "=": (p=.x, q=.y) from obj # Attribute unpacking {0: p, 1: q} from obj # Item unpacking {'x': p, 'y': q} from obj # Item unpacking Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 05/25/2016 02:04 AM, Franklin? Lee wrote:

On Wed, May 25, 2016 at 1:52 AM, Nick Coghlan wrote:

...

Using the running demo:

def demo(arg): given arg: case x, y, *_: # Tuple matching (implicit name binding) ... case (.x, .y) as p, q: # Attribute matching ... case (["x"], ["y"]) as p, q: # Item matching ... case (.x) as p and isinstance(p, int): # Match + condition ... case if isinstance(arg, int): # Condition only ... else: # Default ...

The other key change there is introducing "as" to the individual cases in order to be able to separate the match pattern definition from the local name binding.

I still don't like that `case THING` is a pattern, rather than a value to test against. Here's my modifications with "as", attributes, and

def demo(arg): given arg: case as x, y, *_: # Tuple matching (implicit name binding) ... case as object(x=p, y=q, **_): # Attribute matching ... case as {'x': p, 'y', q, **_}: # Item matching ... case as object(x=p, **_) and isinstance(p, int): # Match + condition ... case if isinstance(arg, int): # Condition only ... else: # Default ...

'case' is the signal word, 'as' is the seperator word -- but it should be separating user stuff, not keyword and all the user stuff clumped together. `case blah blah as blah blah reads much better to me, and clearly says "the stuff between 'case' and 'as' will now be known as the stuff between 'as' and ':'". -- ~Ethan~

On Wed, May 25, 2016 at 5:26 AM, Paul Moore wrote:

On 25 May 2016 at 10:04, Franklin? Lee wrote:

...

Problem: `Point(x, y, ...)` is a legitimate function call, so if `Point(x, 0)` is a legal pattern (i.e. no distinguishing syntax between values and bindnames), you'd need the syntax to be `Point(x, y, *...)`. Personally, I'd require that everything is a bindname (unless it looks like a constructor call), and require checks to be in guards.

With the above syntax, "bare" values aren't a valid match, so in a match, Point(x, y) can never be a function call, it must be a match "Object of type Point, with x and y attributes (which we check for but don't bind)".

I mean a function call, in particular a constructor call. Take these examples, written as constructor destructure assignment: Point(x, y) = obj Point(x=_, y=_) = obj I'd say that Point(x, y) binds two positional constructor arguments, and Point(x=_, y=_) binds attributes .x and .y to throwaway variables. (`object` takes no positional args, and I want it to start allowing keyword args.) Here's my proposed implementation again: Call Point.__asmatch__(obj, nargs, keys, args, kwargs) (where "asmatch" might be an enhanced "__getnewargs__"), with these params: - obj: The object to destructure, which is an instance of Point (possibly typechecked by the match engine before calling). (Note that we're not calling obj.__asmatch__(nargs, ...), to give superclasses a chance to destructure a subclass instance.) - nargs: Number of positional args. - keys: Keyword args specified. - args: Whether or not *rest was used. (Extension: Whether or not splat was used, and whether to discard them.) - kwargs: Whether or not **rest was used. (Extension: and whether to discard them.) It will return (args: tuple, kwargs: dict) if the match is possible. It will check whether there are enough positional args, and whether all keys were valid, and perform the logic about the optional params (giving up as few args and kwargs as possible). Contract: The returned tuple and dict _should_ be valid for Point(*args, **kwargs). This constraint is not necessary if "discard" was specified for anything. My problem is, this would then be ambiguous: Point(0, ...) = obj # Match if the first arg is 0 and the second is `...`? while this would not, but might be ugly. Point(0, *...) = obj

Nikolaus Rath writes:

Or maybe:

if <thing> ... matches <matcher>: pass matches <matcher>: pass

Where "..." is an actual syntactic element that replaces the ":" in a regular if.

Interesting, but I don't like it because (1) ":" is *the* compound syntax indicator in Python, (2) "..." looks like somebody forgot to fill in a blank, *and it should* look that way, (3) "matches" is too close to "match" (which is a stdlib identifier), and it's an identifier I have used, and (4) it's an additional keyword. Leaving aside the spelling quibbles, following "if" I would "see" "matches" as an operator, and want to write if <thing> matches <matcher>: pass elif <thing> matches <matcher>: pass and I'm back in "if ... elif ... else ..." land. I don't really see much advantage to your particular spelling, as to me it doesn't have the connotation that Paul requires (correctly, IMHO) of a single "subject" tested against multiple "predicates". It just "looks wrong" to me. IMHO, YMMV, etc. It *is* interesting, I am trying to contribute to discussion, not end it. My mind could be updated. :-)

On 05/25/2016 07:59 PM, Chris Angelico wrote:

On Thu, May 26, 2016 at 12:34 PM, Stephen J. Turnbull wrote:

...

Leaving aside the spelling quibbles, following "if" I would "see" "matches" as an operator, and want to write

if <thing> matches <matcher>: pass elif <thing> matches <matcher>: pass

and I'm back in "if ... elif ... else ..." land.

What if it were like this:

if <thing> ...: matches <matcher>: pass matches <matcher>: pass

with a colon at the end of the first line too?

I would just as soon use the switch/case keywords, with extra matching oomph. It doesn't have to match C(-like) exactly, and would be immediately recognizable as to the intent (following tests are against the thing in the switch portion). I think it's okay to put our own Python spin on it. -- ~Ethan~

On 26.05.2016 05:50, Ethan Furman wrote:

I would just as soon use the switch/case keywords, with extra matching oomph. It doesn't have to match C(-like) exactly, and would be immediately recognizable as to the intent (following tests are against the thing in the switch portion).

I think it's okay to put our own Python spin on it.

I think "test one thing against multiple conditions" is a quite abstract thing to do. I would like to see some real-world use-case for this kind of syntax. Best, Sven

On May 25 2016, "Franklin? Lee" wrote:

On Wed, May 25, 2016 at 1:52 AM, Nick Coghlan wrote:

...

Using the running demo:

def demo(arg): given arg: case x, y, *_: # Tuple matching (implicit name binding) ... case (.x, .y) as p, q: # Attribute matching ... case (["x"], ["y"]) as p, q: # Item matching ... case (.x) as p and isinstance(p, int): # Match + condition ... case if isinstance(arg, int): # Condition only ... else: # Default ...

The other key change there is introducing "as" to the individual cases in order to be able to separate the match pattern definition from the local name binding.

I still don't like that `case THING` is a pattern, rather than a value to test against. Here's my modifications with "as", attributes, and

def demo(arg): given arg: case as x, y, *_: # Tuple matching (implicit name binding) ... case as object(x=p, y=q, **_): # Attribute matching ... case as {'x': p, 'y', q, **_}: # Item matching ... case as object(x=p, **_) and isinstance(p, int): # Match + condition ... case if isinstance(arg, int): # Condition only ... else: # Default

I think all the ideas with "as" are difficult to read. I think its much better to embed the target variables in the pattern - we just need a way to mark them as such. Mathematica has the same problem and solves it with a trailing _, but we can't do that because our variables names may contain them. But maybe we could use $? Most people already strongly associate this with variables. Example: given foo case (x,y): # matches if foo == (x,y) case (x, $y): # matches if len(foo) == 2 and foo[0] == x, # and assigns y = foo[1] case {'bar': $x, y: $z}: # matches if foo is a map that has 'bar' and y keys # and assigns x = foo['bar'], z = foo[y] case $x.bar: # matches if hasattr(foo, 'bar') and assigns x = foo Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

On 26.05.2016 19:11, Paul Moore wrote:

On 26 May 2016 at 17:21, Sven R. Kunze wrote:

...

I think "test one thing against multiple conditions" is a quite abstract thing to do.

I would like to see some real-world use-case for this kind of syntax Today, I was parsing a job output file. For each line in the file, I tested it against various patterns/conditions to see what type of line it was. Depending on the type of line, I did something different. I used a chain of if/elif statements, because that's what Python currently (3.5) provides, but it would have been an obvious case for a match/switch statement. If the important thing here is *structural* matching then what I actually did was call split() on the line to get a list of elements, then wanted some to be constants, and I picked data out of others. Something like

match line_parts: case _, 'Job', 'Start', start_time: do_something1(start_time) case _, 'Job', 'End', end_time: do_something2(end_time) case view, 'size', 'is', kb, 'KB': do_something3(view, kb)

Is that the type of example you had in mind? Paul

Interesting to see that you chose chains of if-elses. I wouldn't. Especially because our guidelines tells us to avoid *elses* and *ifs* if possible. But here, it's also my personal preference of avoiding a switch-case-like mess. So, in this particular case, I would have used a datastructure for describing how to work with the incoming data. That gives me three advantages over a syntax-using solution: 1) a datastructure (like a dict) would be first-class and I could move it around, manipulate it etc for whatever reason 2) I am able to run separate tests for the matching algorithm (aka finding the right mapping) without applying mocks for *all* possible match-cases 3) no monolithic code block that tends to grow It is also interesting to see that it worked for you. I can remember a similar task quite some time ago. However, there, I needed regular expressions to solve the issue at hand. So, a simple structural unpacking didn't suffice. However, a loop over a list of (regex, action)s with a single check made it work for me. Btw. Django uses this way of matching for the URLs system. And because it needs to be modular (different apps can contribute to it), it would be pointless to have a syntax for it. Even dynamic changes would not be possible with syntax which we do in various places because of, well let's call it, our customer requirements. ;-) My point here is not that not somebody could make use of it (apparently it would for you). However, the absence of it forces people to invent other more flexible mechanisms and I'd actually like it this way. This said, I could rather imagine a new function introduced to functools which provides some sort of match-and-dispatch functionality which you actually do above. Not sure if somebody already suggested this on this thread. Best, Sven

Nikolaus Rath wrote:

I think its much better to embed the target variables in the pattern - we just need a way to mark them as such.

maybe we could use $?

I'd like to suggest using '?' instead. It looks more pattern- matchy to me. Trying to come up with some real-looking examples: switch obj: case Point(?x, ?y): print("Point at", x, y) case Line(start = ?p1, end = ?p2, width = ?w): print("Line from", p1, "to", p2, "with width", w) case Intersection(?obj1, ?obj2): print("Intersection of", obj1, "and", obj2) switch command: case ("frobulate", ?inp, ?out): print("Frobulating", inp", "to give", out) case ("frobulate", "-v", ?inp, ?out): print("Frobulating", inp, "verbosely to give", out) case ("xyzzy", ?) print("Xyzzying not implemented, sorry.") else: print("Couldn't grok your command, master.") Here I've also used '?' without a following name as a "don't care" marker. -- Greg

On Fri, May 27, 2016, 3:21 AM Stephen J. Turnbull wrote:

it is the nested case where I would really like destructuring.

After more than 100 notes in the dict unpacking thread, I've come to the same conclusion. Python already has great tools via tuple unpacking, comprehensions, sets, and the various well-thought methods. Destructuring even a shallowly nested dictionary needs either ugly nested loops or helper functions.

Nikolaus Rath wrote:

class Point: def __init__(self, y, x): self.y = y self.x = x

would your first example assign x == obj.x or x = obj.y?

The intention is that positional args in the pattern correspond to positional args in the object's constructor. To make that work, there will have to be some protocol for reversing the construction of an object. It's been suggested that pickle's __getinitargs__ could be re-used for this purpose. Or we could add a new one called __unpack__ or __uninit__ or something. If the object doesn't explicitly say how to unpack itself, iteration could be used as a fallback. Since your example above doesn't do either of those, it would raise an exception when used in a match statement. -- Greg

On 05/27/2016 06:32 PM, Greg Ewing wrote:

Nikolaus Rath wrote:

...

class Point: def __init__(self, y, x): self.y = y self.x = x

would your first example assign x == obj.x or x = obj.y?

The intention is that positional args in the pattern correspond to positional args in the object's constructor. To make that work, there will have to be some protocol for reversing the construction of an object.

Meaning we can *only* match on constructor arguments? What about attributes that are not set in the constructor, are we just out of luck for those? -- ~Ethan~

On Wed, May 25, 2016 at 7:52 AM, Nick Coghlan wrote:

On 25 May 2016 at 15:11, Chris Angelico wrote:

...

On Wed, May 25, 2016 at 3:03 PM, Stephen J. Turnbull wrote:

...

How about

for <thing>: try <matcher>: pass try <matcher>: pass

Look Ma! No new keywords! Yeah, I know, "for" and "try" both have very strong connotations in Python already, so this may be a "not even the Dutch could like it" automatic-parser-only syntax.

I'd much prefer a different keyword instead of 'for'. If 'with' hadn't been used, that would be a better choice. Maybe 'using'... or 'switch'. But without iteration, 'for' is going to be very confusing.

As a variant on Guido's original switch/case idea:

given EXPR [as TARGET]: case MATCH_PATTERN [as TARGET] [and CONDITION]: ... case MATCH_PATTERN [as TARGET] [and CONDITION]: ... case if CONDITION: ... case MATCH_PATTERN [as TARGET]: ... else:

Just a small comment regarding the possible new keyworks: I very much prefer to use 'given' and 'when' instead of 'switch' and 'case': given EXPR [as TARGET]: when MATCH_PATTERN [as TARGET] [and CONDITION]: ... when MATCH_PATTERN [as TARGET] [and CONDITION]: ... when if CONDITION: ... when MATCH_PATTERN [as TARGET]: ... else: One reason for this is that 'given' and 'when' are less likely to collide with existing variable names. In fact, there are already variables named 'switch' and 'case' in the standard Python distribution. I haven't found any for 'given' and 'when'. Also, given .. when is already used in Perl 5 [1] and 6 [2]. Another alternative is to reuse 'if' instead of 'when'. But I'm not sure if that would make things very confusing. [1] http://perldoc.perl.org/perlsyn.html#Switch-Statements [2] https://doc.perl6.org/language/control#given Manuel.

Franklin? Lee wrote:

On May 28, 2016 4:48 AM, "Greg Ewing" mailto:greg.ewing@canterbury.ac.nz> wrote:

...

No, keyword pattern args should probably match either keyword constructor args or attributes.

That would make things ambiguous and tricky, wouldn't it?

My feeling is that for any well-designed object they should be compatible. If an object has a constructor keyword arg and an attribute with the same name but they mean different things, that object is confusing to begin with. -- Greg

Michael Selik wrote:

On Sun, May 29, 2016 at 7:00 PM Greg Ewing mailto:greg.ewing@canterbury.ac.nz> wrote:

My feeling is that for any well-designed object they should be compatible. If an object has a constructor keyword arg and an attribute with the same name but they mean different things, that object is confusing to begin with.

What about Fraction -- it has ``numerator`` and ``denominator`` for keyword arguments, but also has an extra stuff like ``real`` and ``imag`` inherited from Complex?

All of those names are distinct, so there's no problem there. All of them would be usable as keywords when unpacking. Additionally you would be able to unpack 'numerator' and 'denominator' positionally, because the constructor accepts those positionally. -- Greg

What about a `__match__()` magic function: so given object: case Point(x,y,3):print(x,y) case Point(1,2,3):something_magic() case x,y,Point(a,b,c),1:this_is_my_tuple() be same than writing try: x,y=Point.__match__(object,("x","y",None),(None,None,3)) except MatchError: try: Point.__match__(object,(None,None,None),(1,2,3)) except MatchError: try: x,y,var1,var2=object #literal testing if var2 != 1: raise MatchError() a,b,c=Point.__match__(var1,("a","b","c"),(None,None,None)) #var1 and var2 would not be really created, they are placeholders except MatchError: #nodefault raise else: this_is_my_tuple else: something_magic() else: print(x,y) and let the __match__ functions know what to do to check if arguments are correct I purposely did let drop the dictionary and keyword arguments cases, finding them too much hard to understand 2016-05-30 20:35 GMT+02:00 Steven D'Aprano :

On Sat, May 28, 2016 at 02:13:33PM +1200, Greg Ewing wrote: [...]

...

Finally we could allow "case class" to be abbreviated to just "class":

switch obj: class Intersection( class Line(class Point(?x1, ?y1), class Point(?x2, ?y2)), class Line(class Point(?x3, ?y3), class Point(?x4, ?y4))):

Is that unacceptably verbose? I don't know.

Verbose, not so much. Cryptic? Hell yes! Who is going to be able to guess what it means? We're no longer even in the same galaxy as executable pseudo-code.

Try this as an exercise: given the above, explain in plain English what it does and what the result will be. What exactly is being matched?

Those familiar with C-like switches are going to be totally confused. They'll probably wonder if you are matching "if obj == the class Intersection", and have no idea what's going on with the nested Line and Point stuff.

Those familiar with classes and the class keyword are going to wonder what class definitions are doing inside the class declaration. Does this mean we can now do this?

class Child(class Parent: pass): def method(self): ...

Obviously not, but that's what it looks like.

I wonder whether the real problem here is that pattern matching as a concept is simply too concise for mere mortals? Once you get past the trivial Haskell-esque:

def factorial(n): switch n: 0: return 1 n: return n*fact(n-1)

its just doing too much in too little code to be easily comprehensible.

-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/