Get back `check_argument_types` and `check_return_type`

albertz commented 6 months ago

Things to check first

[X] I have searched the existing issues and didn't find my feature already requested there

Feature description

Bring back check_argument_types and check_return_type.

There is quite a lot of code out there which uses check_argument_types and check_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/363

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

agronholm commented 5 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.

agronholm commented 5 months ago

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?

albertz commented 5 months ago

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:

They can modify the behavior of the method/function in a way that I don't see at the same place. They can have side effects that I don't see. I like to do things more explicit. (That's a big reason for me.)
Static type checkers, IDEs (e.g. PyCharm) etc usually get confused about the types, don't support auto-completion and/or type checks properly anymore. (Also a big reason. I like my auto-complete and warnings by the IDE when I do sth wrong.)
Decorators might break some code in various ways, e.g. when combined with other decorators, or when there is other code inspecting the method attributes, or maybe in combination with metaclasses, staticmethods, classmethods, etc. Some of those bugs are also not easily detected directly. You cannot be sure that by introducing decorators to some method, that everything will behave 100% the same as before. (Otherwise I would just make those edits to those projects and corresponding PRs. But I don't because I'm not sure if it might break something.)

agronholm / typeguard