Twitter user @DanyX23:

TIL: pyright, the python type checking engine that is used by VS Code, has support for exhaustiveness checking for match statements with union types!

If you add the following to your pyproject.toml, you’ll get the attached warning

[tool.pyright] reportMatchNotExhaustive = true

  • @KindaABigDyl
    27•15 days ago

    This is honestly so frustrating to see bc I’ll still never understand why Python isn’t just statically typed.

    It’s right there in the Zen:

    Explicitness is better than implicitness

    It wouldn’t even have to be less simple as it could still be weakly typed, a la Rust or Haskell, but not as robust.

    You wouldn’t need these extra special tools if the language was just built right!

    Same goes for the try/catch exception system where runtime errors can pop up bc you don’t have to handle exceptions:

    Errors should never pass silently.

    Unless explicitly silenced.

    Python is a good language that could’ve been a great one smh

    • @[email protected]
      8•15 days ago

      I mean thats one of the big points of python and why you wanna use it in the first place.

      I personally don’t main python but to me this all seems like a effort to retrofit the language for use in large enterprise and web applications, something for which it honestly never should have been used this heavily in the first place. I guess the state of the world 10 years ago let to it, with .NET not officially being multiplat, Java being Java and Rust, Kotlin and Go being in their infancy.

      To me Python always was a cool language to write small scripts to automate certain things. Something a single developer writes with < 10K LoC. Where than you can achieve the same thing with way less code and less hastle like setting up a seperate build tool

      If your gonna go heavy on typing and error handling but don’t want the complexity of a compiled language just use a .NET or JVM lang, honestly. They are fundamentally built around strong typing and use that information for much better performance and developer experience.

      Or if you just want THE most flexible typesystem where you can specify types as broad or specific as possible typescript takes the cake.

      • @[email protected]
        5•15 days ago

        I write Python and Typescript with full typing for my day job, and it’s pretty nice. Here’s the general workflow:

        1. Add some code without typing
        2. Iterate on 1 until it works properly
        3. Add tests and types
        4. Submit code for review

        In development I get the benefit of most of the types being specified, but I don’t need to specify everything until I’m done. I much prefer Python to Typescript, but my hands are tied on the FE.

        If I needed better performance though, I’d write in Rust, which is actually what I use for most of my hobby projects.

    • Eager EagleEnglish
      4•15 days ago

      Same goes for the try/catch exception system where runtime errors can pop up bc you don’t have to handle exceptions

      I see three possible ways to go about errors:

      1. Make the programmer actually handle (not just bubble up) all possible errors, which will at some point break abstractions and make writing any piece of code an exhausting task.
      2. Make it easy for programmers to ignore errors silently. The worst option IMO as it risks undefined behavior and creates bugs that are hard to replicate.
      3. Make it easy to surface errors to the caller and halt the execution if unhandled. This is what Python exceptions do and I believe to be the best compromise. Bubbling up errors is given by the language and does not depend on the programmer’s willingness to check for errors like in Go (also no err != nil checks all over the codebase).

      The criticism I have to Python exceptions is that there should be a way to explicitly see the exceptions a function raises, maybe as part of the function signature like in Java.

      To put it another way, I don’t think errors as returned values are immediately better than exceptions. I like the way Rust handles them for instance, but an unsuccessful .unwrap() is not that different from an unhandled exception. I just wish the possible exceptions raised were explicitly stated.

    • @[email protected]English
      2•15 days ago

      There are various ways to monitor and handle types, they just aren’t set up right out of the box. It’s not uncommon for a language to be greatly enhanced by libraries/extensions. Having a robust development environment and standards are just part of writing good code.

      This is not an apology for python not having it all out of the box, I think it should. Some things.just take setup and for now thats how it is.

    • @[email protected]OP
      0•15 days ago

      I feel like Python is coming to its senses in the recent years, with releases focusing on typing constructs and the match statement. I think they’re on the path to be a great statically typed language, don’t you think?