Python Type Hints – *args and **kwargs

Re:Python Type Hints – *args and **kwargs by zbentley on Sunday August 27, 2023 @10:32AM (#37283094)

What about decorators, or wrappers around third-party code whose contracts change frequently (or even second party code when interacting with functions provided by teams that don't follow explicit argument typing guidelines, if you have that sort of culture)?

[ Parent | on HN ]

Re:Python Type Hints – *args and **kwargs by refactor_master on Sunday August 27, 2023 @11:01AM (#37283348)

Usually the solutions range from a culture of “just don’t” to tests/mypy that have become increasingly stricter over the years, every time we’ve come a step further up the ladder. But I admit, it has taken quite some bridging to get there.

Moving to static Python in most places has dramatically improved the code and language.

[ Parent | on HN ]

Re:Python Type Hints – *args and **kwargs by voz_ on Sunday August 27, 2023 @03:18PM (#37285759)

As someone that works on a Python compiler, this is a very limited view of reality…

[ Parent | on HN ]

Re:Python Type Hints – *args and **kwargs by dcgudeman on Sunday August 27, 2023 @08:40PM (#37288276)

Can you explain a bit more?

[ Parent | on HN ]

Re:Python Type Hints – *args and **kwargs by plonk on Sunday August 27, 2023 @01:00PM (#37284486)

Those are better handled by typing.ParamSpec, it should keep track of the unwrapped function's arguments.

[ Parent | on HN ]