LWN: Comments on ""Structural pattern matching" for Python, part 2"

"Structural pattern matching" for Python, part 2

udifuchs — Fri, 18 Sep 2020 04:23:15 +0000

I know that a computer parser could easily understand this syntax. Still, as a human, I find it confusing. Most keywords in python are followed by an expression. The case keyword is followed by a pattern that has a syntax similar to an expression. This is confusing.

The PEP mentions that assignment targets in python also look like expressions, but this is true in a very narrow way. It is a syntax error to write 'int(x) = 3', while 'case int(x):' is valid.

More specifically, while reading the is_tuple() example in the PEP, it took me a while to realize that LParen() is initialized in the original code but not in the new code. If LParen.__init__() has some side effects, the two versions of the code that look very similar could be very different.

"Structural pattern matching" for Python, part 2

HelloWorld — Wed, 16 Sep 2020 16:02:20 +0000

> Dispatching on types is just not a good way to write code in a dynamically typed language. There is no - and can be no - exhaustiveness checking for example, to give just one example of why it's a problem.

That problem has nothing to do with pattern matching and everything to do with dynamic typing, which is quite simply an inherently bad idea.

"Structural pattern matching" for Python, part 2

HelloWorld — Wed, 16 Sep 2020 15:59:52 +0000

> case Point2D(x, y):
>
> It looks like the class is being initiated.

No, it doesn't, because there is a case keyword right before it, it's pretty much impossible to miss. If the reader doesn't know what that means and starts making wild guesses, the problem isn't with the language but with the reader.

"Structural pattern matching" for Python, part 2

udifuchs — Tue, 15 Sep 2020 13:28:42 +0000

The syntax that I find confusing is the class pattern matching:

match pt:
case Point2D(x, y):

It looks like the class is being initiated.
I was wondering if using square brackets would make more sense,
as it is similar to the syntax used for type annotations.
For example:

match pt:
case Point2D[x, y]:

One issue with this idea is that the square bracket use might be confused with
item access. In enum, for example, this is a valid syntax:

>>> Sides["SPAM"] == Sides.SPAM == Sides("Spam")
True

Resolving this conflict would probably require not allowing such item access
inside a case statement.

"Structural pattern matching" for Python, part 2

plugwash — Sun, 13 Sep 2020 11:11:35 +0000

> You are correct that a PyObject is a tagged union.

I would argue it's more akin to a base class than to a tagged union with the "ob_type" field serving a role similiar to a vptr.

To me at least "tagged union" implies that the list of subtypes is determined in advance and sufficient memory is allocated to store any of the subtypes.

"Structural pattern matching" for Python, part 2

milesrout — Sat, 12 Sep 2020 04:30:26 +0000

>Is there any indication that something better than `isinstance` if-trees was explicitly rejected earlier in the language's design process?

Yes. Switch statement suggestions have been rejected over and over again. Pattern matching proposals have been rejected before. 'if isinstance' isn't considered bad Python because it's *ugly* but because it's *bad design*. Dispatching on types is just not a good way to write code in a dynamically typed language. There is no - and can be no - exhaustiveness checking for example, to give just one example of why it's a problem.

>but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).

Adding type annotations to Python is yet another example of the continual application of bad ideas to clutter up Python, done by people trying to roleplay as Haskell programmers. Pattern matching is the same thing. It's blatant cargo culting.

"Structural pattern matching" for Python, part 2

mathstuf — Fri, 11 Sep 2020 13:27:14 +0000

> It's not supported by the language *for good reason*.

This feels like one of those "cannot derive ought from is" statements. Is there any indication that something better than `isinstance` if-trees was explicitly rejected earlier in the language's design process? I'd expect the previous approach was "just treat it like a duck and if it quacks well enough, what do you care?", but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).

"Structural pattern matching" for Python, part 2

milesrout — Fri, 11 Sep 2020 12:53:54 +0000

And what I am saying, quite clearly I think, is that I do not think that that is the right thing to be doing in Python code. It's not supported by the language *for good reason*.

"Structural pattern matching" for Python, part 2

johill — Fri, 11 Sep 2020 06:29:32 +0000

Well, that's a question of your architecture/design, but a large part of the whole point of the match statement was to be able to match different types in the same place.

"Structural pattern matching" for Python, part 2

mathstuf — Thu, 10 Sep 2020 13:21:58 +0000

Ah, I see now what you're doing. Yes, that's a nifty trick (assuming you can guarantee that you're only using rebound variables rather than holding a window into a variable someone else eventually mutates). But it's Python and I consider that kind of thinking just necessary for making robust software in that language.

"Structural pattern matching" for Python, part 2

milesrout — Thu, 10 Sep 2020 02:12:08 +0000

That's quite intentional. If you are passing the wrong type of value to a function then your code should crash. The code will also crash if I pass a string to a function that expects an integer. Code should not be full of defensive checks for programmer error: they're code paths that are hard if not impossible to test and by design are intended to never be run (nobody makes programmer errors on purpose). Type checks are for dispatching based on type in Python, and most of the time 'isinstance' checks are the wrong way of doing things. "if isinstance elif isinstance elif isinstance"-style code is considered unPythonic, and I don't think that papering over that code with a language construct makes it a good idea.

Now there are possibly some cases where you want to be able to pass different sizes of tuples to a single function. However I think in most of those cases you probably shouldn't be using tuples, you should be using something like a named tuple, a dictionary, a custom class, a dataclass with an optional field, or just separate arguments to a single function, some of which are optional.

Or possibly you should actually be making a decision 'am I working with 2-tuples or 3-tuples?' at a higher level and switch. If you had some code that is meant to work with 2D or 3D or 4D vectors for example, it would be better to have separate functions for the length of 2D, 3D and 4D vectors than a single function that does


    def veclen(v):
      match v:
        case (x,y): return sqrt(x*x + y*y)
        case (x,y,z): return sqrt(x*x + y*y + z*z)
        case (x,y,z,w): return sqrt(x*x + y*y + z*z + w*w)

Then you should make the determination as to whether you are working with 2D, 3D or 4D vectors at a high level and write all the functions dealing with 2D, 3D or 4D vectors separately.

For example if you really want to write 'length-agnostic' code with tuples up to some maximum length, then you should encapsulate that variation in size in Vector2D, Vector3D and Vector4D etc. classes with a common Vector superclass such that Vector's methods can be those that are parametric in the dimension.

And if it's really truly length-agnostic tuple code then you should be writing loops over lists, not matching on tuples.

"Structural pattern matching" for Python, part 2

milesrout — Thu, 10 Sep 2020 02:11:40 +0000

That's conflating two separate things: capturing names and capturing names that refer to mutable values.

>>> a = 0
>>> b = []
>>> f = lambda: print(a)
>>> g = lambda a=a: print(a)
>>> h = lambda: print(b)
>>> i = lambda b=b: print(b)
>>> (f(), g(), h(), i())
0
0
[]
[]
>>> a = 1; c.append(3)
>>> (f(), g(), h(), i())
1
0
[3]
[3]

f captures the *name* 'a', which refers to the immutable value 0. g has an optional parameter, the default value of which is the value of a i.e. the immutable value 0. Like any Python function, g will store internally references to the default values for its parameters. It can't 'capture' the variable a because you could put *any* expression as the default value for g's parameter, and that expression is evaluated *when the function is defined*, with the resulting value stored inside the closure object somewhere.

When f is called, it prints a i.e. the value referred to by the name 'a' that f captured. If 'a' has changed then what f prints will change. When g is called, it prints the value of its parameter or if it isn't given one, the default value, which is zero. The 'a' in f refers not to the value that 'a' had when f was created, but to the name 'a' itself in the definition environment of f.

When a is rebound to 1, it doesn't change the value that a was originally bound to. 'a = 1' is an operation on the name 'a', not an operation on the value pointed to by a. We reassign 'a' so that it refers to a different value, but we don't modify the value that 'a' previously pointed to. So when f() is called a second time, it prints 1 (the new value pointed to by a) while when g() is called a second time it prints 0 (the value you can think of as being pointed to by some 'g.__internal_stuff__.parameters[0].default_value' attribute).

h and i actually work exactly the same way, but with one crucial difference: the value that the name 'b' refers to is a list and is thus mutable. So when we do the 'b.append(3)' operation we are not changing the name 'b'! We're modifying the value *pointed to by b*. When we defined i, we evaluated the expression "b" and pointed some internal "this is the default value of my parameter" field of the closure object at the result of that evaluation. Evaluating the expression "b" results in that list object, the list object pointed to by the name 'b'.

So when we call h(), it prints the value pointed to by the name 'b'. When we call i(), it prints the value of parameter, if it exists, or the value pointed to by some internal 'default' reference for that parameter. That default reference hasn't been changed, it still points to the same object. However that object itself has been changed by the call to append. We only ever created *one* list object, and there are two references to it.

The 'mutable default value' issue for Python functions basically has nothing to do with variable capture at all. It's present even for normal function definitions:

def foo(x=[]):
x.append(1)
print(x)

>>> foo()
[1]
>>> foo()
[1, 1]

The main problem that the variable capture issue causes happens even with immutable values, and in fact is primarily an immutable value issue. The first time I encountered it was with a GUI library. I was doing something like this:

>>> for i in range(5):
>>> buttons[i].on_click(lambda: buttons[i].colour = RED)

but of course the problem with this is that all the buttons will make the last button red when clicked. That's not because of a mutable value: the value pointed to by i doesn't change. The problem here is that a for loop assigns to the iteration variable. That code is the same as writing

>>> i = 0
>>> buttons[i].on_click(lambda: buttons[i].colour = RED)
>>> i = 1
>>> buttons[i].on_click(lambda: buttons[i].colour = RED)
etc.

And there it's more clear what's happening vis a vis name capture. The solution is of course to instead write buttons[i].on_click(lambda i=i: buttons[i].colour = RED).

"Structural pattern matching" for Python, part 2

johill — Wed, 09 Sep 2020 22:16:11 +0000

Your version crashes if you pass it a 3-tuple or something else.

The match/case version can handle such things without you having to put another "is a 2-tuple" if outside of it.

"Structural pattern matching" for Python, part 2

mathstuf — Wed, 09 Sep 2020 14:37:40 +0000

Hmm. That doesn't seem fool-proof:

>>> d = []
>>> f = lambda x=d: print(x)
>>> f()
[]
>>> d.append(3)
>>> f()
[3]

Unless I'm missing what you're trying to capture here?

"Structural pattern matching" for Python, part 2

milesrout — Wed, 09 Sep 2020 13:37:46 +0000

Python used to have simple and pleasant syntax. With async/await, := assignment and now this, the syntax seems to be getting significantly more complex with every new version of the language for very little benefit.

"Structural pattern matching" for Python, part 2

milesrout — Wed, 09 Sep 2020 13:37:36 +0000

At that point, how is this better than


(x, y) = size
if x == y:
    circle()
else:
    ellipse()

I would contend that it is not. It is an extra level of indentation and a whole new complicated language construct.

"Structural pattern matching" for Python, part 2

milesrout — Wed, 09 Sep 2020 13:37:25 +0000

And of course there is in also a very easy solution: lambda i=i: i captures i “properly”. Perhaps not very intuitive for beginners, but once you've learnt it you've learnt it.

"Structural pattern matching" for Python, part 2

johill — Wed, 09 Sep 2020 06:22:09 +0000

> As long as CapturedVar suitably 'ducks' its type (e.g. for ints, implementing + and **, like you suggested), Point.__init__ should be entirely happy with it unless it's trying to do things that depend on the actual values.

I don't think that'll work. It has to implement the algebraic operations to build a parse tree to be able to do algebraic matching, but you still can't really call Point.__init__ with it I'd think, it might check the type, or other random things in there. Hence the match protocol though!

> Sure, it's not something that will work for every class, but nor is the rest of the "Match Protocol" in PEP 622. And if the class has a __match_args__, then you could potentially have a matching.Duck that uses that to "play the rôle of" the class in a match expression: [...]

But yeah, you're right, the PEP also cannot do magic wrt. class matching, it has __match_args__ for that, and indeed with something like the "Duck()" you propose - or what I wrote as "m := matches_instance(Point, capture.x, capture.y)" - you can indeed do the same thing.

I neglected to think enough about it I suppose, but (fairly obviously) the only magic in the PEP can be the syntax, making "Point(x, y)" not be an instantiation call but some other kind of expression. Without new syntax we have to open that up manually by doing "Duck(Point)(capture.x, capture.y)" or my "m := matches_instance(Point, capture.x, capture.y)".

The rest ... yeah can probably be done, now that I think about it. In mostly the same ways.

And that shows to some extent where and how the algebraic matching breaks down and probably why they punted on it, though I'm not convinced it's that bad. Obviously, you don't want to get into the territory of writing "Point(x**2, x**3)" and suddenly needing an arbitrary solver to do the match, but I think you could do it if you restrict to having to mention each variable "naked" at least once. I.e. "Point(x, x**3)" would be OK and "Point3d(x, y, x+y)" would also be OK - all of this because once you have values for x/y it's easy to check the remaining expressions. But something like "Point(x+y, x-y)" would not be allowed.

"Structural pattern matching" for Python, part 2

ecree — Tue, 08 Sep 2020 23:39:39 +0000

because you quite probably cannot instantiate a Point() object with two CapturedVar instances.

But can't you, though?

As long as CapturedVar suitably 'ducks' its type (e.g. for ints, implementing + and **, like you suggested), Point.__init__ should be entirely happy with it unless it's trying to do things that depend on the actual values.

Sure, it's not something that will work for every class, but nor is the rest of the "Match Protocol" in PEP 622. And if the class has a __match_args__, then you could potentially have a matching.Duck that uses that to "play the rôle of" the class in a match expression:

from matching import match, capture, Duck

with match(p) as matches:
    if m := matches(Duck(Point)(capture.x(int), capture.x(int))):
        print("Diagonal at %d" % (m.x, ))
    elif m := matches(capture.p(Point)(capture.x(int), capture.y(int))):
        # the second call on capture.p implies a Duck
        # if the match succeeds, it is replaced with the concrete Point
        print("Other point at %s % (m.p, ))

So you'd use plain Point() for dataclasses and anything else that's not too fussy, Duck(Point)() otherwise.

Still not quite as pretty as the PEP 622 syntax, but it still seems like a good way to get experience with "how this feature would be used in practice" before baking it into the language. Which to my mind is reason enough to do it.

"Structural pattern matching" for Python, part 2

johill — Tue, 08 Sep 2020 18:33:48 +0000

But actually...

while all of that works nicely with tuples because you can build some knowledge of them into the code, it really doesn't work at all with what the PEP calls "Class Patterns".

You can't write "m := matches(Point(capture.x, capture.y))" because you quite probably cannot instantiate a Point() object with two CapturedVar instances.

so you'd have to rewrite that as something like "m := matches_instance(Point, capture.x, capture.y)" at which point (pun intended) new syntax seems to make sense...

"Structural pattern matching" for Python, part 2

johill — Tue, 08 Sep 2020 17:39:44 +0000

I also just realized that I sort of sketched the basics of "algebraic matching", where the original PEP completely bypassed that issue and (x, x) doesn't even do what seems obvious? Or am I reading that wrong?

Of course some more complex expressions would be ... hard. Probably not impossible, but hard. You'd have to make the CapturedVar() be able to track all kinds of things, if you wanted to be able to write

...
    if m := matches((capture.x(int), capture.x(int)**2)):
        print("Integer point on the parabola at %d" % m.x)
...

It still seems possible, but ... tricky to say the least. Effectively, "CapturedVar" would have to be able to be operated on in a symbolic fashion, always returning a new CapturedVar object that encapsulates the expression, and can later evaluate it. So given an instance

  x_square := CapturedVar('x') ** 2

you'd have to be able to calculate

x_square(7)

so you can compare to

capture.x(7)

But you can see the ambiguity here! I previously allowed

capture.x(int)

to indicate you wanted a specific type ...

This would be better if the types were to rely on type annotations, but I don't think you can do that in this fashion.

I suppose you could detect if the argument was a type or an instance or something? But tricky to differentiate ...

Oh, I have an idea. The

x_square(7)

calculation is purely internal, so we can do it as

x_square(value=y)

(say the signature is "__call__(self, type=None, value=None)" so you can differentiate more easily. The value passing syntax is only needed internally to evaluate when you have a given thing in hand.

Well, basically ... it get complex, but I haven't hit anything I couldn't do.

Now I'm tempted to actually implement it :-)

"Structural pattern matching" for Python, part 2

ecree — Tue, 08 Sep 2020 16:15:12 +0000

> But I believe it can be done.

I agree. And that's a clever idea of yours to use a context manager to get the 'only mention p once' semantics.

"Structural pattern matching" for Python, part 2

johill — Tue, 08 Sep 2020 07:34:43 +0000

Sorry, obviously in both cases the first if was meant to be

    if m := matches((capture.x(int), capture.x(int))):
      print("Diagonal at %d" % (m.x, ))

And that of course shows that the matches() call needs to be fairly smart about disentangling instances of CapturedVar() etc. But I believe it can be done.

"Structural pattern matching" for Python, part 2

johill — Tue, 08 Sep 2020 07:29:40 +0000

And maybe CapturedVar() can be callable again, returning another CapturedVar() instance with a type attached, so you can write

  from matching import match, capture

  with match(p) as matches:
    if m := matches((capture.x(int), capture.y(int))):
      print("Diagonal at %d" % (m.x, ))
    elif m := matches((0, capture.y(int))):
      print("X-axis at %d" % (m.y, ))
    elif m := matches((capture.x(int), capture.y(int))):
      print("Point at (%d, %d)" % (m.x, m.y))
    elif m := matches((capture.x, capture.y)):
      raise ValueError("It's a tuple, but not with integers")
    else:
      raise ValueError("Not a 2-tuple")
  return Point(*p)

"Structural pattern matching" for Python, part 2

johill — Tue, 08 Sep 2020 07:21:17 +0000

You can probably use some more "magic" to make that shorter, something like

  from matching import match, capture

  with match(p) as matches:
    if m := matches((capture.x, capture.y)):
      print("Diagonal at %d" % (m.x, ))
    elif m := matches((0, capture.y)):
      print("X-axis at %d" % (m.y, ))
    elif m := matches((capture.x, capture.y)):
      print("Point at (%d, %d)" % (m.x, m.y))
    else:
      raise ValueError("Not a 2-tuple")
  return Point(*p)

You need something like

class CapturedVar:
  def __init__(self, name):
    self.name = name

class capture:
  def __getattr__(self, name):
    return CapturedVar(name)

and "match(...)" returns an object that is callable; the called method knows about CapturedVar instances and bumps those into the returned MatchedVars object ("m").

"Structural pattern matching" for Python, part 2

ecree — Mon, 07 Sep 2020 16:45:37 +0000

On thinking more about this, I have a fairly fundamental question, which I didn't see raised anywhere:

Why can't this be done as a library? Why is a language feature needed?

Something like

    import matching

    # ...

    if m := matching.match(p, (matching.capture('x'), matching.capture('x')):
        print("Diagonal at %d" % (m.x,))
    elif m := matching.match(p, (0, matching.capture('y')):
        print("X-axis as %d" % (m.y,))
    elif m := matching.match(p, (matching.capture('x'), matching.capture('y')):
        print("Point at (%d,%d)" % (m.x, m.y))
    else:
        raise ValueError("Not a 2-tuple")
    return Point(*p)

Yes, it's more verbose than the 'match' statement, but mainly because of the length of names, and still much more concise and declarative than doing everything with isinstance() and len(). And it makes the difference between constants and capture variables totally explicit!

"Structural pattern matching" for Python, part 2

smitty_one_each — Sun, 06 Sep 2020 21:18:19 +0000

I hadn't heard of "Fear Of Missing Out" before. Thanks.

It does seem that, with the newer release cycle, Python is going down the Java "featuritis" road.

On the other hand, this seems to take Python more in a Haskell-ish direction.

Good news? Bad news? Who can say?

On the other hand, the languages that fail to add new features seem to be the ones nobody's using any longer. It's more of an economic than technical arms race, apparently.

"Structural pattern matching" for Python, part 2

kleptog — Sun, 06 Sep 2020 11:35:20 +0000

An alternative to algebraic pattern matching is allowing extra conditional, like in elixir (which also offers algebraic matching). Then it could look like:

match size:
    case (x,y) if x == y:
        circle()
    case (x,y):
        ellipse()

The whole power of such a match statement is that you can match entire nested structures, which this PEP does offer. An optional extra if clause for the more fancy cases can help here.

"Structural pattern matching" for Python, part 2

mathstuf — Fri, 04 Sep 2020 16:04:23 +0000

I was worried about the same thing too, but the walrus operator saves you in this related case as well:

match t := some_expr():
    case ...:
    case _:
        # use t

Though I don't like the locality mismatch here. For a large (probably considered un-Pythonic) match, your variable assignment is far away when it could be right next to it. You also have to consider that `t` is now always assigned to rather than just in the catch-all case.

"Structural pattern matching" for Python, part 2

ecree — Fri, 04 Sep 2020 15:54:00 +0000

Apparently the PEP authors decided to punt on what they call "algebraic matching" of repeated names.

IMNSHO, if this PEP isn't doing algebraic matching then it's really far from clear what it's for, and I'm tempted to side with those who say this creature is being feeped purely for the sake of feeping.

"Structural pattern matching" for Python, part 2

gray_-_wolf — Fri, 04 Sep 2020 11:31:54 +0000

Given that the same variable in the match multiple times is illegal, how is one supposed to match things like Point with x == y?

I would have assume that

match p:
case (x, x):

would match points where p.x == p.y. However that does not seem to be the case. How can I express such a match?

Second question, if constants must be namespaced, is there no way to express something like:

x = 1
match p:
case (x, y):

For points that are `(1, .*)`? Is there something like `local` namespaces for local variables in python?

I'm not a python programmer, so I might be lacking some parts of the proper mindset, but it seems... limiting.

"Structural pattern matching" for Python, part 2

NYKevin — Thu, 03 Sep 2020 22:48:04 +0000

lambda does create a new lexical scope already, and it doesn't help with that problem. In order for your example to work "correctly," you would need to establish a new lexical scope for each iteration (not just one for the whole loop, because it would still have i=4 at the end of the loop). I would find that very hard to reason about, because that's not what I think of when I hear the word "lexical."

What (I think) you really want is capture-by-value semantics instead of capture-by-name, which has nothing to do with whether or not the loop has a separate scope.

"Structural pattern matching" for Python, part 2

jcpunk — Thu, 03 Sep 2020 16:38:43 +0000

I agree. I've yet to be convinced this is actually any better than

if XXX:
  print(x)
elseif YYY:
  print(y)
elseif ZZZ:
  print(z)
else:
  raise ValueError()

"Structural pattern matching" for Python, part 2

sbaugh — Thu, 03 Sep 2020 14:17:32 +0000

>Moreover, I've never run into a situation where it actually causes a problem of some sort.

Isn't the fact that Python functions aren't true closures a direct consequence of its lack of proper lexical scope? I'd say that causes a *lot* of problems:

>>> fs = [lambda: i for i in range(5)]
>>> [f() for f in fs]
[4, 4, 4, 4, 4]

"Structural pattern matching" for Python, part 2

hartb — Thu, 03 Sep 2020 13:22:42 +0000

I guess you still have the object-to-be-matched handy:

match t:
    ...
    case _:
        print("error: ", str(t))

"Structural pattern matching" for Python, part 2

NYKevin — Thu, 03 Sep 2020 07:06:51 +0000

> Yes, I anticipated that. I think it would be worth it, since the only way to get reasonable scopes in current Python involves nested functions or lambdas, but in the end that's not for me to decide.

How exactly would you define "reasonable?"

IMHO, the Python rule is very straightforward and easy to remember. Moreover, I've never run into a situation where it actually causes a problem of some sort. Sure, variables hang around for a little longer than they would otherwise, but so what? If you really care, you can explicitly write del x, which is probably a Good Idea anyway, because if you care, then you should call attention to the fact that you care (not-caring is the default state of affairs, so x must be special in some way).

> Making it harder to mess around with frame objects seems like a feature, not a bug. Making them completely inaccessible would be even better.

And while we're at it, let's put the e in creat(2), where it should've been all along.

You can't break backcompat on a feature just because you personally dislike that feature. It exists. It needs to be supported. Unless we want to do *another* 3.x-style flag day, frame objects are here to stay.

> I think that could be avoided by simply defaulting to function scope as current Python does when assigning to an unknown variable.

As I mentioned in the comments the last time we discussed this idea:

- There is no such thing as an "unknown" variable, except at the global scope.
- It is always possible to determine at compile time which variables belong to which scopes, with the exception of the global scope. The bytecode compiler will then emit bytecode that only consults the single scope where the variable actually lives, or consults the global scope if the variable is not recognized.
- The global scope is not known at compile time, for a number of reasons, most obviously the fact that from foo import * is legal at the global scope (it's a SyntaxError anywhere else). This doesn't matter, because the "unknown = global" algorithm is good enough for the current design.
- Because the global scope is not known at compile time, it is not possible to determine at compile time whether an unrecognized variable in a match expression is a global or a nonexistent variable that should be created and bound to the case's scope.
- Therefore, allowing match expressions to create a new scope does not actually solve this problem, and would introduce a significant amount of complexity for no adequately justified reason.

"Structural pattern matching" for Python, part 2

nybble41 — Wed, 02 Sep 2020 23:24:59 +0000

> Changing variable scope to be anything other than the parent function/class/module declaration would be a massive change.

Yes, I anticipated that. I think it would be worth it, since the only way to get reasonable scopes in current Python involves nested functions or lambdas, but in the end that's not for me to decide.

> Anything digging around in frame objects would need to learn to poke wherever these new scopes end up being declared.

Making it harder to mess around with frame objects seems like a feature, not a bug. Making them completely inaccessible would be even better. (And, apart from debugging, how would you even use such a thing without creating a very tight coupling with the function's internal implementation? I'm not seeing any realistic scenario where this code would not need to be updated anyway.)

> You'd basically need to add variable declarations too…

I think that could be avoided by simply defaulting to function scope as current Python does when assigning to an unknown variable. Nested block scopes would be introduced by specific statements where binding makes sense such as loop variables in a "for" statements, "as" clauses in "with" statements (as per the original version of PEP 343[1]), or placeholders in "match" statements. A "local" keyword could be added to explicitly introduce scoped variables into the current block, similar to the "global" and "nonlocal" keywords, if there is a demand for it.

[1] https://docs.python.org/2.5/whatsnew/pep-343.html

"Structural pattern matching" for Python, part 2

mathstuf — Wed, 02 Sep 2020 21:32:47 +0000

Changing variable scope to be anything other than the parent function/class/module declaration would be a massive change. Anything digging around in frame objects would need to learn to poke wherever these new scopes end up being declared. You'd basically need to add variable declarations too since this fairly common pattern would be broken:

if foo is not None:
    local_foo = foo
else:
    local_foo = DefaultValue()

(Sure, here `foo` could probably be reused, but code like this still exists.)

"Structural pattern matching" for Python, part 2

nybble41 — Wed, 02 Sep 2020 21:25:14 +0000

Maybe I just lack a properly Pythonic mindset, but the most bizarre part of this proposal to me is the fact that the names are *assigned* rather than *bound* within the lexical scope of the match arm. Every other language I know of with pattern matching creates lexical bindings for match variables rather than allowing the match itself to have side effects on existing variables. If the match placeholders were bound lexically then it would make perfect sense that they can't be qualified. As implicit assignments, however, the restriction does seem a bit arbitrary. At the moment Python appears to lack a concept of lexical block scope. Perhaps that deficiency should be rectified before moving on more advanced features like pattern matching.

"Structural pattern matching" for Python, part 2

mb — Wed, 02 Sep 2020 19:25:01 +0000

we chose a simpler rule: named constants are only recognized when referenced via some namespace, such as `mod.var` or `Color.RED`

Oh, come on...

That is even more awful than using cryptic special characters like dots.
That means whether a variable is read from or written to depends on how I "fetch" a variable name.

The equal character would IMO be the obvious and intuitive character to mark that something is going to be assigned to.

match t:
    case (USE_RECT, real=, imag=):
	return complex(real, imag)
    case (USE_POLAR, r=, phi=):
	return complex(r * cos(phi), r * sin(phi))