Typeguard | Hacker News Reader

Typeguard

typeguard.readthedocs.io

67 pointstosh19 comments

Python ecosystem is getting more verbose and less ergonomic than Haskell while still not being able to reach even the minimum level of type safety of the latter (i.e. a default compiler mode without extensions like GADTs, type families and so on). At the same time Haskell ecosystem is getting more ergonomic and "pythonic". Consider these two complete and fully typed minimal programs. Why do they keep saying that Python is great for small scripts?

    import Data.Foldable (for_)

    main = do
        let words = ["Hello", "World"]
        for_ words (\word -> print word)

    from typing import Iterable

    def main() -> None:
        words: Iterable[str] = ["Hello", "World"]
        for word in words:
            print(word)

    if __name__ == '__main__':
        main()

Your Python example has unnecessary type annotations. Python type checkers like mypy and Pylance can infer the type of `words` automatically.

    def main() -> None:
        words = ["Hello", "World"]
        for word in words:
            print(word)

    if __name__ == '__main__':
        main()

Yes and no. That particular example can indeed be type-checked without extra annotations (unless I want to indicate that the use-case of the variable is actually immutable). But consider I slightly modify the script:

    def main() -> None:
        words = []
        for word in (words + ["Hello"]):
            print(word)

        if __name__ == '__main__':
            main()

MyPy rejects to infer the type of the iterable. Here's an equivalent Haskell version that does infer the type without manual annotations:

    import Data.Foldable (for_)

    main = do
        let words = []
        for_ (words ++ ["Hello"]) (\word -> print word)

typescript can infer it too:

  function main() {
      let words = [];
      for (const word of [...words, 'Hello']) {
          console.log(word);
      }
  }

> Why do they keep saying that Python is great for small scripts?

I think comparing hello world is a bit unfair. A script may have something like file manipulation, regex, http requests.

Typing in small scripts is pointless. The type annotations are only useful for large codebases

Various automation/pipelining scripts benefit greatly from typing, as it at least provides a level of assurance that data of proper shape is passed to relevant functions at all times. It helps especially when the automation scripts parse and extract and concatenate yaml portions from larger configs. I wouldn't want to write manual unit tests just to ensure shapes' validity.

Not the poster, but this library is completely undervalued. I am a big fan of it.

Using standard type annotations in python and adding some @typechecked annotations can be much easier than adopting mypy in an organisation. It helps adopting typechecking incrementally for people who would never decide to adopt it otherwise, and it brings benefits immediately.

In my opinion the best way to get started with typing annotations in Python is just having an editor that understands type hints.

Unless your environment requires you to use Python e.g. data science I just wonder why not use something with types to begin with.

I agree, but it is not enforced. When I see a @typechecked annotation I know that the tests touching that path will blow up if the type is not correct. With intellij or Visual Studio code it is more of an hint (pun intended) one cannot rely on.

In my experience, even if the ORG or TEAM does not adopt the policy of adding type annotations, I just do it anyways. They might not use mypy, but I do.

One caveat is I've stopped adding type annotations for anything but the most latest Python versions. Mainly because I got tired of having to deal with importing modules for things like unions, or whatever container types... all of that should be in the core language, and in more recent python that is happening.

I think having a strictly-typed language is completely undervalued, especially when ones solution is to use a library that only attempts to enforce types at the runtime level (as I understand).

Why not trying to catch type issues earlier than in Prod?

I agree with your sentiment. It is nice to use a strictly-typed language but Python is not one. Not all projects/teams I take part in want to change languages.

On the other side, this runtime error can be triggered by the tests in a ci/cd pipeline. While not ideal, in practice this can end up being much earlier than in production.

When would you do the switch to mypy and why?

In addition to performance, I would switch when the idea is to have the whole codebase, or a specific part of it, typechecked at "compile time". This way it can be part of a ci pipeline or a precommit hook, instead of blowing up with a good descriptive error (typeguard) but at runtime.

Typeguard has a performance hit as it runs at runtime, on the other hand it provides better type safety than mypy.

What happens with mocks?

Maybe click the link? "Support for mock objects" is a section in the table of contents sidebar on the User Guide:

https://typeguard.readthedocs.io/en/latest/userguide.html#su...

Reply on news.ycombinator.com