Hacker News Reader

Couldn't agree more! I've been using Python for almost 20 years, my whole career is built on it, and I never missed typing. Code with type hints is so verbose and unpythonic, making it much harder to read. Quite an annoying evolution.

As the article says, type hints represent a fundamental change in the way Python is written. Most developers seem to prefer this new approach (especially those who’d rather be writing Java, but are stuck using Python because of its libraries).

However it is indeed annoying for those of us who liked writing Python 2.x-style dynamically-typed executable pseudocode. The community is now actively opposed to writing that style of code.

I don’t know if there’s another language community that’s more accepting of Python 2.x-style code? Maybe Ruby, or Lua?

There is nothing python-2 about my python-3 dynamically typed code. I'm pretty confident a majority of new python code is still being written without type hints.

Hell, python type annotations were only introduced in python 3.5, the language was 24 years old by then! So no, the way I write python is the way it was meant to be, type hints are the gadget that was bolted on when the language was already fully matured, it's pretty ridiculous painting code without type hints as unpythonic, that's the world upside down.

If I wanted to write very verbose typed code I would switch to Go or Rust. My python stays nimble, clean and extremely readable, without type hints.

I agree completely! To be clear, I don’t consider describing code as “Python 2-style” to be a bad thing. It’s how I describe my own Python code!

Overall, I have found very few Python 3 features are worth adopting (one notable exception is f-strings). IMO most of them don’t pull their weight, and many are just badly designed.

> Hell, python type annotations were only introduced in python 3.5

Mypy was introduced with support for both for Python 2.x and 3.x (3.2 was the current) using type comments before Python introduced a standard way of using Python 3.0’s annotation syntax for typing; even when type annotations were added to Python proper, some uses now supported by them were left to mypy-style type comments in PEP 484/Python 3.5, with type annotations for variables added in PEP 526/Python 3.6.

> Need to iterate over a collection of things?

Iterable[T]

> Want to create a data object that maps any hashable type to just about anything else?

Mapping[T, U]

Beyond the advantage that a type-checker/linter can tell if you're doing the right thing when writing those functions, it lets an IDE infer what type you're iterating over, in order to provide more support/completion/hinting/checks (without recursively analyzing arbitrary code, so: 'instantly' vs 'maybe not ever).

> Duck typing is one of the best things about Python.

And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing.

> If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen

I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types (but I also like that typing being optional means that its very easy to toss out exploratory code before settling on how something new should work.)

> I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types

Same.

Type hints also basically give me a "don't even bother running this if my IDE shows type warnings" habit that speeds up python development.

Absence of warnings doesn't guarantee me bug-free code but presence of warnings pretty much guarantees me buggy code.

Type hints are a cheap way to reduce (not eliminate) run time problems.