Python’s “type hints” are a bit of a disappointment to me

Re:Python’s “type hints” are a bit of a disappointment to me by saila on Sunday April 24, 2022 @02:06PM (#31146548)

Learning any new syntax, feature, etc takes time. IME learning type annotations can pay major dividends. For example, I wrote some type-annotated code the other day and mypy pointed out a couple places where I was passing the wrong type, which saved me from having to fix those bugs later, thus saving time for "actual work."

[ Parent | on HN ]

Re:Python’s “type hints” are a bit of a disappointment to me by nine_zeros on Sunday April 24, 2022 @06:54PM (#31149045)

There is a recurring cost to complex type annotations and that is that every single developer working on that repo (could be thousands) has to unravel the complex types, their aliases and the instance objects to modify any code.

This as opposed to a legitimate type system where complex types are classes themselves which don't need unraveling. There is no need to alias a type and there is no need to maintain separate complexities for the object and the type.

[ Parent | on HN ]

Re:Python’s “type hints” are a bit of a disappointment to me by saila on Monday April 25, 2022 @04:43PM (#31160351)

I agree that complexity could be an issue with Python's typing, which has some flaws, although it's been improving.

Type aliases are okay if they're not overly complex, having used them in Python and other languages to good effect, e.g. to avoid duplication or for clarity.

I'd suggest using type annotations where it's not overly onerous--which is probably most places--to get the benefits without much effort but perhaps avoid them or use simplified types where it's too complex.

I also agree that there are places where typing is unnecessary and doesn't add much value, such as in certain scripts.

Like many things in programming, it's all about finding the right trade-offs.

[ Parent | on HN ]