3 ms·

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 annota

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 4y ago
When would you do the switch to mypy and why?
- withakay 4y ago
  Typeguard has a performance hit as it runs at runtime, on the other hand it provides better type safety than mypy.
- mejutoco 4y ago
  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 4y ago
In my opinion the best way to get started with typing annotations in Python is just having an editor that understands type hints.
- mejutoco 4y ago
  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 4y ago
  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 4y ago
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 4y ago
  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 4y ago
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.

funerr 4y ago

When would you do the switch to mypy and why?

withakay 4y ago
Typeguard has a performance hit as it runs at runtime, on the other hand it provides better type safety than mypy.
mejutoco 4y ago
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 4y ago

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

mejutoco 4y ago
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 4y ago
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 4y ago

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 4y ago
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 4y ago

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.