Open albertz opened 6 months ago
I never intended for these to be used by library authors. My goal was always to provide noninvasive type checks, but it took me a long while to figure out how to do that. But now it sounds like the cat is out of the bag, and library authors have started using these checks that I threw away. I'll need to think about it, but progress has been slow as I haven't been maintaining this project very actively as of late.
Wait, these projects are pinning typeguard to v2.13, not even 4.0? Can you elaborate on why you would want to avoid the decorator?
I think v2.13 was the last version with check_argument_types and check_return_type?
I'm not affiliated with those projects, so I can only tell for myself why I don't like decorators:
Things to check first
Feature description
Bring back
check_argument_types
andcheck_return_type
.There is quite a lot of code out there which uses
check_argument_types
andcheck_return_type
and where authors do not want to update because they prefer the old API, or it's just too much effort to rewrite. https://github.com/PaddlePaddle/PaddleSpeech/pull/3056 https://github.com/espnet/espnet/pull/5009 https://github.com/ExaWorks/psij-python/pull/363Also, one could argue,
check_argument_types
was simpler to use, it did not require a decorator. There could be reasons why you want to avoid using a decorator.(I'm not sure if this feature request makes sense. I just want to raise awareness of the fact that a number of projects stick to old typeguard versions because of this. This is causing problems now for me because I want to use some of those projects (ESPnet) together with some own code which uses a new typeguard version, and this does not work now because of the incompatibility.)
Use case
Be able to update to newest version.