You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.)
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.PaddlePaddle/PaddleSpeech#3056
espnet/espnet#5009
ExaWorks/psij-python#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.
The text was updated successfully, but these errors were encountered: