HN Explorer

19 comments

[ 1.9 ms ] story [ 54.4 ms ] thread
mejutoco
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.

funerr
When would you do the switch to mypy and why?
withakay
Typeguard has a performance hit as it runs at runtime, on the other hand it provides better type safety than mypy.
mejutoco
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.
nicolaslem
In my opinion the best way to get started with typing annotations in Python is just having an editor that understands type hints.
mejutoco
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.
romanovcode
Unless your environment requires you to use Python e.g. data science I just wonder why not use something with types to begin with.
chrisandchris
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?

mejutoco
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.

parasense
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.

ghostwriter
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)
vs

    from typing import Iterable

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

    if __name__ == '__main__':
        main()
animal_spirits
Typing in small scripts is pointless. The type annotations are only useful for large codebases
ghostwriter
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.
MapleWalnut
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()
ghostwriter
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)
tejinderss
typescript can infer it too:

  function main() {
      let words = [];
      for (const word of [...words, 'Hello']) {
          console.log(word);
      }
  }
Zababa
> 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.