Hacker News Reader

Comment by oconnor663 | Hacker News Reader

https://github.com/JelleZijlstra/unsoundness is also a great collection of Python type system holes. In these cases, it's mostly deliberate design decisions, not bugs. The unfortunate fact is that a fully sound Python type system would be a pain to use.

View on HN

> The unfortunate fact is that a fully sound Python type system would be a pain to use.

Even beyond Python, most gradual type systems are unsound by design.

Perhaps I'm just an old dog that doesn't want to learn new tricks, but I still can't think of Python as typed and I never use type hints. I started with Python during the 2.3 era. I still view Python types as merely docs. So it's nice that someone tracks mypy quirks but I can't imagine relying on the results for anything serious.

To be very pedantic, Python was always strongly typed in the sense that every value has a concrete type. This is very different to, e.g. C, where `void*` is often used to actually erase the type or, conversely, more abstract languages where there are only interfaces.

But of course Python function were always duck typed so it often didn't matter to the user.

Well, Python has a static type systems, it's just that everything has the same static type. We should call these 'unityped' languages, not 'untyped'.

If you deal mainly with small-to-medium size Python programs, which is probably the norm, that makes sense to me. But if you have a large Python application, or if you own a library API that might have a lot of callers, typecheckers catch sooo many mistakes.

Not really, I measured it.

Typing prevents 1 minor bug per developer per year reaching the testing environment.

It costs 2x development time to use. (With LLMs it's doubles token usage, very measurable)

It's not actually a sane trade-off.

I've been writing python for closing in on two decades (I want to say maybe 2.5 was my introduction point?).

I've found type hints to be remarkably useful and catch significantly more bugs than I ever would have thought, and have quickly picked up the practice of using them wherever I code. My general finding is that if I have to struggle to put useful type hints in place, I probably need to rethink my code.

I even type hint my unit tests because I've learned that sometimes type incorrectness means my tests haven't been testing what I thought they were testing.

Frameworks like pydantic[0] can help you turn those type hints into something runtime enforcing too.

[0] https://pydantic.dev/docs/validation/latest/get-started/

Generally speaking, static typing is the great enabler of writing bad Python code.

As soon as static typing is introduced into a Python code based, the developers start writing unscalable coding patterns that don't scale to larger programs.

You can't rely on Python's type hints for serious verification, but it can be great for expressing abstractions and giving people (and, today, agents) better affordances for using them. Even static errors that will not always fire can still help a lot for using a library correctly and for noticing mismatches in your codebase as it evolves over time.

Reply on news.ycombinator.com