Hacker News Reader

Comment by doug_durham | Hacker News Reader

How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.

View on HN

> For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false.

No, it is correct. The value None is not with the domain of type int, a parameter that can take the value None does not in fact have type int.

> This yields no value because when you say `= None` you are saying that this is an optional argument.

When you provide any default value, you are making the argument optional, but that's an orthogonal concern to the Optional[T] type, which doesn't mean “optional argument", it is simply a more convenient way of expressing Union[T, None], though with the modern type syntax, T | U is generally more convenient than either Union[T, U] or Optional[T] for U=None.

No offense, but this sounds like user error. I rarely have irrelevant type warnings. If I do, it suggests something is wrong with my design.

If you declare a function parameter as `foo: int = None`... that is just an incorrect declaration. Of course a variable annotated as `int` can take a `None` value, but that is because any variable can take any type in Python. Within the Python type (annotation) system it is simply the case that an `int` and an `int | None` are two different things, as they are in other languages (eg Rust's `T` vs `Option<T>` types).

Mypy used to support the "implicit optional" feature you describe but now you must make nullable arguments explicitly optional. This is in line with Python's "explicit is better than implicit" design philosophy. In any case, how long does it take you to just type `foo: int | None = None`? Or you could re-enable the old behavior to allow implicit optionals with `--implicit-optional` or the corresponding config file option. It seems like you just need to configure mypy to match your preferences rather than fighting with its defaults.

To return to the broader point, I'm unsure what an "irrelevant type warning" is, but I suspect that has something to do with my lack of appreciation for dynamic typing. Can you give an example that isn't just a complaint about typing an extra 6 characters or about mypy being misconfigured for your preferences?

No offense taken. I've had a long career with many different phases. I had a phase where I built palaces of types bordering on DSLs. I ended up building myself a straight jacket. I wasn't solving the customer problem, and I was only slowing myself down. Software is an engineering discipline. Every situation needs to be critically evaluated. Building a life-critical single point of failure component is much different than building a road over a culvert. In early languages you needed to specify types so the compiler knew how much space to allocate for storage. In languages like Python, type hints are more like documentation. It helps the reader understand how to use your code. It can be used for correctness. However if correctness is a primary criteria driven by engineering requirements I'd probably consider another language and accept that it is going to cost more and be slower to develop.

Reply on news.ycombinator.com