1. 36
  1.  

  2. 16

    This part feels like a real missed opportunity:

    https://www.python.org/dev/peps/pep-0622/#check-exhaustiveness-at-runtime

    The question is what to do if no case clause has a matching pattern, and there is no default case. An earlier version of the proposal specified that the behavior in this case would be to throw an exception rather than silently falling through.

    The arguments back and forth were many, but in the end the EIBTI (Explicit Is Better Than Implicit) argument won out: it’s better to have the programmer explicitly throw an exception if that is the behavior they want.

    Python has a lot of useful dynamic checks. For example:

    • calling a function with the wrong number of arguments
    • accessing a field that doesn’t exist
    • 2 + "3"

    These checks are all implicit, and that’s good!

    Errors should never pass silently.

    Unless explicitly silenced.

    1. 4

      I really want pattern matching to get in, but I legit worry about pattern matching in Python in general.

      The main thing that Python tends to do is make it really clear what a symbol refers to. Explicit self, stuff like quit being an actual object instead of some REPL hack… the classname thing seems slightly magic-y.

      On top of that the hand-wave-y-ness of the implementation makes me worry a lot about the actual implementation. Like if I case-match a list destructuring, is the interpreter going to do a len check before? Or will it attempt a destructure and then raise later? List destructing unpacking semantics are stateful, not stateless:

      l = (a for a in range(4))
      a, b = l # fails with ValueError on unpack
      print(list(l))  # gives [3] 
      # (the above pops 3 values, not 2! since generators
      # work via a `StopIteration`, the third value gets popped in 
      # the "end of iterator" check. You lack the `peek` so to speak
      

      I don’t know what I would rather have here.

      To be honest I feel like doubling down on destructuring would be way more valuable overall. For example getting the Python-equivalent to let {foo, bar} = f() in JS (Though to be honest that’s not that huge of again). isinstance checks overall are not Pythonic, and the isinstance-heavy stuff I’ve had to use (looking at you, Pandas!) tehnds to be pretty miserable.

      I was pretty happy to get Enums when getting to Python 3, but in practice Python isn’t super suited to using them. Maybe this makes it all work nicely! But I have doubts. If we could just get at least C-level switch statements that would be pretty great though.

      1. 2

        This seems useful, even from my perspective as someone who hasn’t used pattern matching before.

        However, I feel like I’m beginning to see a pattern of extra features being added in to (into?) Python in a way that reminds me of C++‘s ever-expanding scope (the only ones that I can recall right now are the walrus operator and type hinting, but the point is that it’s a feeling, not an observation in an experiment). Is this just me?

        1. 2

          Type-hinting has been a long time coming and these others feel IMO more like conveniences than actual scope creep or even Big Things. If template macro stuff was shoehorned in, I’d worry ;)

        2. 1

          Wow they moved fast! I remember Guido van Rossum talking about PEG making pattern matching possible on a conference just last fall. I thought it’d take years :-)

          1. 1

            Why is it that the PEG parser enabled pattern matching?

            1. 3

              I don’t know exactly, but I’m guessing it has something to do with the introduction of match (and case) as new keywords even though they’re still valid identifiers in the language. PEG with its ability to backtrack arbitrarily complex expression makes it possible to recognize match as a keyword only after it parses the rest of the statement, and distinguish it from something an assignment like match[i].attr = "value".

              1. 1

                Ah, that makes sense. Hence the use of soft keyword. I had never heard that term before.

              2. 2

                In the link it says “The match statement uses a soft keyword, and it is one of the first major Python features to take advantage of the capabilities of the new PEG parser. This means that third-party parsers which are not ‘PEG-compatible’ will have a hard time with the new syntax.”

                But I am still not sure about what this actually means.