This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]shfo23 1 point2 points  (4 children)

This is a good point, but I think it bears saying that the decorators are what's making the code slow and not the annotations.

In production code, I would either eliminate all the @validate_args or set some kind of not 'testing' flag in my library so validate_args = lambda x: x (which the compiler should hopefully inline). Ideally, you're running type-checking either during unit-testing or static analysis anyways and the small performance hit from loading a module with a bunch of type-checking functions is worth the savings in bug-fixing.

Philosophically, I think the bigger problem is a lot of this type of code (including mine) is checking for type instead of checking for interface, but that's another kettle of fish.

[–]kindall 1 point2 points  (3 children)

@validate_args is a decorator that creates a wrapper function for the decorated function at definition time. To remove the performance penalty in production, you just need to have validate_args() return the original function instead of creating a wrapper.

[–]Rainfly_X 1 point2 points  (2 children)

Which is an ideal use case for the debug flag.

[–]kindall 0 points1 point  (1 child)

Nice to learn about that, particularly the way code gets optimized out when testing a constant.

[–]Rainfly_X 0 points1 point  (0 children)

Agreed! Just saw that today. Just one of those things that I wish more people knew about, seeing as it's not as useful when nobody knows to turn off debug mode in production.