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

401–410 of 597 posts

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

#401

Post by da39a3ee »

kortex wrote: post #326

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 p…

You’ve never used a compiled statically typed language. I’m sorry to say it but your comment would sound naive to you if you had. The article is spot on.

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

#402

Post by andrewingram »

minism wrote: post #256
tootie wrote: post #254

Earlier quoted context omitted.

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#.

Same thing happened to the JS world with typescript (though typescript seems more powerful than python type annotations). Its fine though - I'm glad the culture is trending towards understanding that strong typing saves you time rather than causes you extra time. This is true even for very small and simple programs, and even if you're the only developer.

TypeScript has a more powerful type system, but arguably it's less powerful because the hints are invisible to runtime code. Python doesn't do any runtime type checking by default, but the hints are accessible in code, which unlocks a fair amount of power. For example, Strawberry is a GraphQL server library that allows you to define your GraphQL schema using the same syntax as dataclasses.

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

#403

Post by oriolid »

rwmj wrote: post #362
bayesian_horse wrote: post #304

Earlier quoted context omitted.

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…

The number of times I've stared at some random Python function deep inside a library wondering what does this function return ? Even the docs often don't say.

It was very productive for the person who wrote the library.

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

#404

Post by goodoldneon »

bayesian_horse wrote: post #299
goodoldneon wrote: post #267

Earlier quoted context omitted.

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:…

This is a misunderstanding of the Python type system. In the Typescript example you are depending on "foo" being structurally compatible to the "Foo" interface. In the Python case, "foo" and "Foo" might look structurally compatible, but they aren't. "Foo" isn't just a type, it's an object of type "class". You can for example print(Foo), you can't console.log(Foo). "foo" is not an instance of the Foo class. What you a…

TypedDicts fall under structural typing, not nominal typing. So Mypy is cool with this:

  import typing
  
  class Foo(typing.TypedDict):
      a: int
  
  def do_thing(value: Foo) -> None:
      return
  
  foo: Foo = {"a": 1}

  do_thing(foo)
My complaint here is that Mypy doesn't go far enough with structural inference. I assume this is because it doesn't support anonymous TypedDicts, whereas TypeScript supports anonymous interfaces/types

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

#405

Post by goodoldneon »

Loeffelmann wrote: post #384
goodoldneon wrote: post #257

Earlier quoted context omitted.

There's a subtle difference between TS' question mark and union. The question mark means "this argument is optional", which can be different than "this argument can be undefined". The following code is valid: function foo1(value?: number) {} foo1() But the following code will raise a type error: function foo2(value: number | undefined) {} foo2() In practice, that rarely becomes problematic. But it's good to know the…

I really think the second one shouldn't raise a type error. This is already invalid: function foo1(arg1?: number, arg2: number) {} In that case you have to use function foo1(arg1: number | undefined, arg2: number) {} foo1(undefined,1); But other than that what is the use case?

The second one raises an error:

https://www.typescriptlang.org/play?#code/AQMwrgdgxgLglgewqB...

This conflation of "optional" and "undefined-able" is more obvious in interfaces. This is why TypeScript added the `exactOptionalPropertyTypes` option:

https://www.typescriptlang.org/tsconfig#exactOptionalPropert...

Sometimes "is not defined" needs to be treated differently than "is set to undefined"

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

#406

Post by PMunch »

ZoomZoomZoom wrote: post #46

> What I want is this: Some language that’s as easy to use as Python and it should be compiled and with good static typing... Well, there's always Nim. [0] > ...but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops? Eh, there's Nimscript? [1] 0. https://nim-lang.org/ 1. https://nim-lang.org/docs/nims.html

Not sure what the compiled != easy to use bit comes from anyways. If anything I'd say that part of Nim makes it easier to use, I don't have to worry about whether or not the target has Python installed.

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

#407

Post by bostik »

NumberCruncher wrote: post #382
bayesian_horse wrote: post #290

Earlier quoted context omitted.

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…

> That doesn't mean an experienced full stack developer would do Data Science better, because he might lack a lot of skills that matter more in that domain. This resonates with my experience. I had the opportunity to work on a DS codebase written entirely in Scala with all the typing, parallelism, actor model, whatnot. Basically I joined the company because of this technical factor. It was fun until I figured out tha…

> integration tests running on real data not on mokups.

I can see you are enjoying the life outside of a highly regulated industry. Having certain kinds of production data in tests (or feeding that to test environment) would be a major audit finding in any finance or healthcare company.

Makes for both a blessing and a curse.

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

#408

Post by Bedon292 »

folkrav wrote: post #204
Bedon292 wrote: post #176

Earlier quoted context omitted.

We use pre-commit and you can't even commit until it passes mypy. It can be a bit frustrating sometimes, but overall it has saved us from a lot of issues.

I like the validation scripts being available in a repo so I can run them locally before pushing to CI, but I also often use WIP commits and quick fixups and then rebase before opening the PR, so pre-commit hooks are really annoying to my workflow. I more often than not just do `git commit --no-verify` or simply delete the git hook in `.git`, then just run it myself before pushing. Anyway CI will catch it, so I don't…

Yeah, when you just want to add a checkpoint WIP commit its annoying. Hate having to fight with that. But it prevents people form submitting a PR and then just having CI fail anyways. I could see it being nice to only enforce on CI though. Sucks seeing those red builds because someone didn't run something manually.

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

#409

Post by Bedon292 »

ohmahjong wrote: post #336
folkrav wrote: post #204

Earlier quoted context omitted.

I like the validation scripts being available in a repo so I can run them locally before pushing to CI, but I also often use WIP commits and quick fixups and then rebase before opening the PR, so pre-commit hooks are really annoying to my workflow. I more often than not just do `git commit --no-verify` or simply delete the git hook in `.git`, then just run it myself before pushing. Anyway CI will catch it, so I don't…

This has been my experience as well, as someone who added a pre-commit hook (black and mypy) to a repo in lieu of adding it to CI (it was a while ago). I came back to the team a year later to find that everyone had simply disabled the hook, and forgone typing/formatting entirely. A day or two of fixing formatting, type hints and linting errors later, the CI pipeline had a new step enforcing all three :)

Our CI pipeline actually just runs `pre-commit run -all` on the repo too. So we know if someone doesn't have it turned on. But I could definitely see taking mypy out of pre-commit, and having it just be a CI step. Rather than waiting the minute on the commit to happen.

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

#410

Post by analog31 »

bayesian_horse wrote: post #304
smohare wrote: post #300

Earlier quoted context omitted.

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately. The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re hav…

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…

In my view it's both. I'm one of those "scientific" programmers. I've used type hints, just to learn it, but tend not to use them in practice. Bugs caused by typing errors seem to be extremely rare in my little world.

I've also programmed extensively in Pascal, assembly, and C. I get it about types. Don't forget C has 8 different types of integers that have to be kept straight. ;-)

On the other hand, I realize that any of my programs is but a little nub of code sitting on top of large and expertly maintained libraries. I'm grateful for whatever the authors of those libraries are doing to keep their sanity, and am not surprised when I see type hints in those codes.

Post reply on HN