Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

uninformativ.de

Post reply on HN
Print view View original

321–330 of 597 posts

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

#321

Post by wronglyprepaid »

reikonomusha wrote: post #268
wronglyprepaid wrote: post #74

Earlier quoted context omitted.

> Yes, they lack teeth. But what’s the alternative? In what way do they lack more teeth than Java with Object, Go with interface{}, C++/C with void*?

Idiomatic C and Go programs aren't labeling everything with those types, and the language implementation enforces those types at compile time. Since types are optional in Python, it's necessarily true that an "Any"-like type is prioritized since it's the default. Moreover, cpython doesn't check anything when it bytecode-compiles. Any-by-default and no-built-in-checking feels pretty defanged to me.

> Since types are optional in Python, it's necessarily true that an "Any"-like type is prioritized since it's the default. Moreover, cpython doesn't check anything when it bytecode-compiles.

mypy is pretty whiny about types, and sure, if you add Any everywhere then you have just defeated the type checker, but this is no different from putting interface{} everywhere for Go.

> Any-by-default and no-built-in-checking feels pretty defanged to me.

Is running mypy on the code base that much to ask?

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

#322

Post by jlrubin »

my experience with python's optional type system was that the simple stuff works very well, but when you try to go down a type rabbit hole for more advanced stuff involving generics it becomes really unworkable, inconsistent, and hard to dig yourself out of.

but for little things, like just function signatures, it's great!

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

#323

Post by grumpyprole »

ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

> can't fully represent heterogeneous values in a dict, given that you can't do this _at all_ in many statically compiled languages.

This isn't really true. For example, in Java it's Map. For languages without subtyping, existential types are often used. It's quite common to see in infrastructural code, e.g. caching.

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

#324

Post by jlrubin »

jlrubin wrote: post #322

my experience with python's optional type system was that the simple stuff works very well, but when you try to go down a type rabbit hole for more advanced stuff involving generics it becomes really unworkable, inconsistent, and hard to dig yourself out of. but for little things, like just function signatures, it's great!

fwiw i was able to successfully port this complex project into rust's type system.

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

#326

Post by kortex »

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling.

My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks. I'm not even sure I'm on the same planet as the author. I can practically spot incorrect type hints, mismatched types, weakly defined interfaces, from orbit, that's how well they are highlighted. Since every type is known, between pycharm and tabnine I can type 2-5 keys and spit out entire lines of code. And since it's all typed, automatic refactor is a breeze.

I remember the dark ages, before type hints. It was rough. I lived in the REPL. Write 3 lines, run, Exception. Write 3 more lines, run, NoneType error. Ad nauseum. Now I write for hours on end and don't wince when I hit execute. And I don't have to go bug coworkers with questions like "hey what keys are in this dict when we redirect from the oauth endpoint".

Sure, I have my gripes, but it's mostly with the lack of power of the type system, like lack of higher kinded types. But I'm confident it'll get there.

Come to the typed side. We have less mental fatigue and screaming at neverending runtime oopsies.

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

#327

Post by dgb23 »

theodorejb wrote: post #97
ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

> 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. Counterexample: PHP is a dynamic language which enforces static type declarations at runtime.

Fun fact: it will still do type coercion in that scenario without strict mode. And you cannot annotate assignments. Otherwise it’s pretty useful.

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

#328

Post by aswerty »

Type hints are a god send in Python if you want to use the language for anything beyond scripting (or single developer code bases).

Without type hints you don't realise how crazy your data structures get in Python. Trice nested dictionaries getting passed around, or pandas running wild across your code base, and on it goes. Instead with type hints we now have insight and can have meaningful discussions on the data structures flowing through our system.

Our team is yet to adopt mypy into our build systems, but hopefully we will introduce it soon.

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

#329

Post by tjoff »

kadoban wrote: post #240
totony wrote: post #183

Earlier quoted context omitted.

>My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. I agree this is useful, but to me the most useful feature of types are the self-documentation. It's crazy the difference between a non-typed library with shitty documentation vs a typed library with shitty documentation.

The types on stitty-documented code often do depend on the types actually being checked though. Otherwise you need to author to be diligent in their types, but if they're bad in their other docs, that seems unlikely.

You don't think that "the author thought that this function would return X, but I got Y" is useful?

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

#330

Post by captainmuon »

just-ok wrote: post #27

Despite this: > Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at runtime. That already exists (most of the time). I want to know about type mismatches in advance. You should check out Typeguard [1], which lets you add a @type_checked decorator to anything and get runtime type checking that's far better than e.g. a random blowup…

Do you know if there is a way to do runtime type checking in the whole program with typeguard, beartype or something else? As far as I know you have to go through and add decorators manually. Typeguard had a profiler hook that almost got it right, but is being removed. Ideally I would want to say 'python3 -m typecheck myprogram.py' and it would run typechecking everything in my code (but maybe not in library code).
Post reply on HN