Live data from Hacker News

Typeguard

typeguard.readthedocs.io

11–20 of 20 posts

Re: Typeguard

#11
post #2

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

Re: Typeguard

#12
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()

Re: Typeguard

#13

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 Pyth…

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

Re: Typeguard

#15

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 Pyth…

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.

Re: Typeguard

#16

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 Pyth…

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()

Re: Typeguard

#17
post #2

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.

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.

Re: Typeguard

#18

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 Pyth…

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)

Re: Typeguard

#19

Earlier quoted context omitted.

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 doe…

typescript can infer it too:

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

Re: Typeguard

#20

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 Pyth…

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

Post reply on HN