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

261–270 of 597 posts

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

#261

Post by reikonomusha »

linsomniac wrote: post #190

Hot take: If you think for a moment about the feature name, "type hints", many (all) of the objections the author has become clear. It is not called "static typing". It's called "type hinting". Based largely on the name, I wouldn't expect it to error at runtime if you tell me 'hello' is an int. That's just a type hint. I WOULD expect a static analysis to flag is, and mypy indeed does.

Aren't they called "annotations" by PEP 484?

Annotating certainly sounds stronger than hinting, but one must dive in and read the PEP to see they in fact do nothing except stash away metadata in a dunder attribute.

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

#262

Post by the_af »

rglullis wrote: post #216
the_af wrote: post #200

Earlier quoted context omitted.

Your "islands" anecdote is amusing, if a bit condescending. Do you honestly think it fairly addresses the very direct question I asked you? Also, do you honestly expect me to detail what my team and company is optimizing for here? What for? What does it have to do with Python type hinting?

The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough. Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who w…

I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking.

I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.

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

#263

Post by coder543 »

tootie wrote: post #254
jsmeaton wrote: post #239

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

There are way more differences between Python and Java than just "having explicit types". If that was the only difference, your comment would make more sense.

I would even go so far as to say that Java's type system is the very one that left such a bad taste in people's mouth that many people swore off explicitly typed languages for a decade or two. It really was that bad, especially before the last few years. It added a lot of extra boilerplate for minimal practical benefit. People used Java because it was fast, cross-platform, and less likely to go horribly wrong than unmanaged languages like C and C++. I doubt very many people used it because they just loved typing tons of boilerplate or because they thought the type system was good enough to catch tons of errors.

The type systems in Rust, TypeScript, and other more recent languages are far more expressive (and capable of catching real-world bugs) than what Java offered. If you think Java has a good type system... things have come a long way since then. Java gets updated continually, and some people will surely jump at my comment and claim things are great these days, but, no. Java is not up to par, even today. C# has done a better job of keeping up, in my opinion, but even it still lacks extremely useful features like proper Sum Types.

I don't have much experience with Python's type hinting, so I can't comment as directly there.

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

#264

Post by the_af »

seti0Cha wrote: post #202
the_af wrote: post #86

Earlier quoted context omitted.

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.

LSP support exists for many editors so you are not tied to a specific IDE. It can catch other programmers mistakes if you run it against their code. It doesn't turn Python into a statically typed language, but it's a lot better than nothing.

Sorry, I wasn't clear. I don't want to mess with each individual developers IDE or setup. I want to enforce type checking at the same place we also run mandatory tests: in the automated build pipeline (think CI/CD).

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

#265

Post by reikonomusha »

dlivingston wrote: post #236
moelf wrote: post #215

My personal "disappointment" is: it doesn't do anything for the runtime with all the extra work and headache. I.e. it feels like Julia but without the elegance of multi-dispatch and performance.

Time-to-first-plot would like a word.

That hardly has to do with type checking, and instead their compiler design.

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

#266

Post by reikonomusha »

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?

Python is compiled, just not to machine code.

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

#267

Post by goodoldneon »

phailhaus wrote: post #67

Python's type system is a disappointment, but I don't think this article does a great job of explaining why. My biggest gripes: 1. There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your…

Agreed. Also, Mypy's dict inference is too broad, making TypedDict a little less useful. For example, the following code raises a Mypy error even though `foo` conforms to `Foo`:

  import typing
  
  class Foo(typing.TypedDict):
      a: int
  
  def do_thing(value: Foo) -> None:
      return
  
  foo = {"a": 1}
  
  # error: Argument 1 to "do_thing" has incompatible type "Dict[str, int]"; expected "Foo"
  do_thing(foo)
But TypeScript can figure it out:

  interface Foo {
      a: number
  }
  
  function doThing(value: Foo): void {
      return
  }
  
  const foo = { a: 1 }
  
  doThing(foo)

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

#268

Post by reikonomusha »

wronglyprepaid wrote: post #74
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*?

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.

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

#269

Post by neves »

jsmeaton wrote: post #239

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

Nice. How do you force types just in the new code?

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

#270

Post by goodoldneon »

chis wrote: post #10

Only facts here. I think most large codebases eventually see type hints drift away from reality as individual contributors are more incentivized to hack in `Any` types to make things compile instead of typing every line properly. This is especially common for handling data objects which come in over the network - often they can have a couple different types but people just type it as one thing for simplicity. Overall…

You can disallow `Any` with the `--disallow-any-explicit` option
Post reply on HN