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

81–90 of 597 posts

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

#81

Post by the__alchemist »

the_af wrote: post #65
davidhariri wrote: post #37

Earlier quoted context omitted.

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.

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

#82

Post by nine_zeros »

gnulinux wrote: post #72
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

It is good for programmers. Programmers think in many different ways, but it seems to me that a sizable portion of programmers think of code in terms types. Type hinting makes it easy to convey type ideas. Where are we going from which type. I should say that anecdotally I find type hinting very useful when I'm reviewing a PR from a part of the code I'm not intensely familiar with.

Just put types in docstrings? Why type hinting with imports and other dependencies, especially for complex objects?

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

#83

Post by smu3l »

What is the precise definition of static typing? Both the article and many comments in this thread refer to static typing or static type hints in Python. But as I've always understood it, static typing means that types are checked and enforced at compile time. And if python is not compiled, the notion of static typing in python does not make sense. So do I have it wrong? Or is the term ambiguous?

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

#84

Post by the_af »

the__alchemist wrote: post #81
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.

I wish the tooling outside IDEs worked better. There's obviously some magic going on with tools like PyCharm and VSCode + plugins.

I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.

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

#85

Post by wronglyprepaid »

the_af wrote: post #53
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…

I can only speak about my own experience: Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff. The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. The type hints themselves are of dubious use. As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often c…

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand.

I use mypy daily on big codebases, it is fine, not fast, but fine.

> The type hints themselves are of dubious use.

They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing different. python with a static type checker running in strict mode is not fundementally different from Java's static type checking.

> As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

What do they lack that would make them useful?

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

#86

Post by the_af »

seti0Cha wrote: post #79
the_af wrote: post #62

Earlier quoted context omitted.

Same here. And I come from (and am a fan of) statically typed languages. The type hinting story for Python seems confusing and not completely useful to me.

I just started using type hinting in Python and I love it. Maybe it's your tooling? I'm using neovim with LSP and pyright and the experience is very much like writing code in a Java IDE. As I code, it informs me where there are mistakes or pieces of code that need to be updated, catches typos, reminds me about forgotten imports, etc. It makes refactoring way easier because as you change signatures or object types it…

I want automated type checking outside the IDE. I want something that will catch other programmer's mistakes, not just mine. Without enforcing a specific IDE.

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

#87

Post by ledauphin »

smu3l wrote: post #83

What is the precise definition of static typing? Both the article and many comments in this thread refer to static typing or static type hints in Python. But as I've always understood it, static typing means that types are checked and enforced at compile time. And if python is not compiled, the notion of static typing in python does not make sense. So do I have it wrong? Or is the term ambiguous?

static in this case can be understood to mean simply "prior to (or separate from) runtime". In other words, it's based on what you can check _without_ running the code.

It's worth noting that nearly every statically-typed language currently in existence has two separate "type systems" - the static type system which is the formal type system offered to the programmer, plus a runtime type system enforced, at minimum, by the processor (e.g. you cannot divide by 0) that is ultimately different from the static type system. The 'question' in most cases is "how closely does the runtime type system match the static type system?" In many if not most languages, the answer is "not very".

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

#88

Post by hermitdev »

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…

Personally, I took exception to the following from TFA:

> Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature.

In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic typing here.

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

#89

Post by the_af »

wronglyprepaid wrote: post #85
the_af wrote: post #53

Earlier quoted context omitted.

I can only speak about my own experience: Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff. The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. The type hints themselves are of dubious use. As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often c…

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. I use mypy daily on big codebases, it is fine, not fast, but fine. > The type hints themselves are of dubious use. They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing dif…

> The same as in literally every other language with static typing

No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either.

> [type hints] tell you when you make type errors

Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking, but a form of notation for documentation. Seems wasteful, and I wish the Python community and tooling decided instead that they are for actually checking them.

> What do they lack that would make them useful?

Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so.

I haven't found mypy to fill these requirements. It's so bad I cannot convince my coworkers to make the effort to write more type hints.

Post reply on HN