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

71–80 of 597 posts

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

#71

Post by wronglyprepaid »

How is a grype with static typing that it is not enforced at runtime? This comes up like once a week, have these people never used statically typed languages?

> The fact that you can put nonsensical types wherever you want and still get a working program has consequences.

Working is questionable, but nothing in C++ prevents this at runtime either, nothing in JVM prevents this at runtime, static typing is not runtime typing, it should not be, it is not the USP.

> There is an Any type and it renders everything useless

Java has object, C++/C has void*, Go has interface{} - none of these render the type system useless, and Python's type system makes it a lot easier to write correct code than Go's type system or C's type system.

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

#72

Post by gnulinux »

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?

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.

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

#73

Post by the_af »

xarope wrote: post #70
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?

as a reminder for yourself/others who need to read/maintain your code? (I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case.

It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

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

#74

Post by wronglyprepaid »

nickysielicki wrote: post #31

Yes, they lack teeth. But what’s the alternative? * fork the language again? We just got out of Python2 hell. * Docstrings, like we had before they were introduced? They won’t catch all bugs, but with minimal effort they’ll catch some bugs, and if you make an effort to really dig in, it’ll catch most bugs. To me, to accomplish that overnight on a language with millions of existing lines, that’s a big win.

> 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*?

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

#75

Post by the_af »

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.

So a concise but not-legally-binding notation for types?

Useful, but way less useful than if it was actually checked.

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

#76

Post by ledauphin »

civilized wrote: post #63
ledauphin wrote: post #55

Earlier quoted context omitted.

This one is self-explanatory. Can a string be printed? Yes! Then Python is (correctly) allowing typesafe behavior here. Your (incorrect) annotation does not in any way contradict the typesafe-ness of printing a string (or an int). They're both equally printable. This is just a very, very bad example, plain and simple. It 'looks' bad to a superficial reading, but in practice it demonstrates only what is already known…

It seems that your point boils down to "Python enforces types at runtime if you define 'enforce types at runtime' not to include 'enforcing that data you declare to be of a certain type actually is of that type'". Am I the only one baffled by this way of thinking?

Python does and always has enforced types at runtime. This is called duck-typing. If you're not familiar with the concept of strong+dynamic, it is easy to see how this could be confusing. This may help. https://stackoverflow.com/questions/2351190/static-dynamic-v...

Static type annotations by definition are not enforced at runtime. This has been true of every language that has ever used static typing, including C, C++, Java, Rust, Typescript... you name it, statically typed languages only enforce their static typing at compile/analysis time.

Yes, it is possible to annotate types in Python incorrectly. It's possible to do this in all other languages that allow type-unsafe behavior (whether natively or via reflection, etc). This may be less common in some languages than in others, but it is fundamentally possible in the vast majority of languages that perform static typing, because those types are fundamentally enforced at analysis time, not runtime.

The author of the article seems to be unfamiliar with these distinctions, and maybe you are too. It's fair to complain that these distinctions are confusing and make things harder for programmers. Nevertheless, very few languages have ever been designed with a type system that acts exactly the same at analysis time and runtime. It's a very difficult problem, partly because these are all abstractions from the perspective of the underlying computer, which only understands boolean logic and integer/floating point math, and has virtually no other notion of types in any formal sense.

Type systems are a complex topic, and as someone who has been paying attention to them for a while, it's frustrating to see uninformed discussion of them show up on Hacker News. That said, it's perfectly understandable that people are confused by these distinctions, and rest assured there's a lot of effort going into developing better languages that suffer _less_ from these issues.

For the everyday working programmer, however, there are currently lots of tradeoffs to be made, and Python's approach to static+dynamic typing is actually pretty usable, all things considered, which is why the community overall has embraced the new static typing despite its blemishes.

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

#77

Post by ungawatkt »

civilized wrote: post #44
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…

> not-very-educated thoughts on gradual typing This seems like an inaccurate and condescending put-down. What is the definition of "educated" in this context? Is there a book or generally well-known resource? The author is clearly thoughtful and curious. Near the top of the post he says "what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system wor…

For 1, there's some unfortunate but important semantics. Python does not enforce type _Hints_ at runtime, as Hints are in many ways fancy comments. But as pointed out, python is a strongly typed language (at least on the sliding scale of strong to weak), and types are known at runtime (call `print(type(var))` to see them). And calling `1 + 'a'` will result in a TypeError exception, unlike say JavaScript.

I believe this is the relavent passage in the article the GP is referencing, which is incorrect if you take "runtime" to mean something like when the line is executed: "Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime."

It _is_ however correct to say you don't know the real type _before_ runtime, at least python does not.

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

#78

Post by [deleted] »

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?

[deleted]

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

#79

Post by seti0Cha »

the_af wrote: post #62
throwaway81523 wrote: post #59

Earlier quoted context omitted.

I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first and I still use it, but I'm not sure at this point that it is worth it.

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 flags all the places in your code that need to be updated. Seems like a real game changer to me.
Post reply on HN