Are you expected to run five Python type-checkers now? • Hacker News Board

Re: Are you expected to run five Python type-checkers now?

#41

Post by kuschku » Mon, Jun 08, 2026, 3:33 PM UTC

voidUpdate wrote: post #3

> "In Python, any method __eq__ is expected to return bool, and if it doesn't, then we need to explicitly tell type-checkers to ignore the type error. This function in Polars can also return different types depending on the inputs, thus requiring overloads." Why would you ever want a == b to not return a bool?? EDIT: Yes, I understand that you can do element-wise equality checks on numpy arrays now

Primarily, because Python doesn't have quasi-quoting. You can't pass an expression without workarounds like this.

Re: Are you expected to run five Python type-checkers now?

#42

Post by MeetingsBrowser » Mon, Jun 08, 2026, 3:34 PM UTC

dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

strict type checking is an incredibly useful tool for cases when you really want to make sure your code is correct and behaving as expected (one of many tools).

There are lots of people who like python and want to use it for things that where incorrect code has serious consequences. Type checking is helpful in these contexts.

Type checking remains optional for the masses and is not practical in many cases. Still, pushing away people who want to use all available tools for writing correct python only hurts the community.

Re: Are you expected to run five Python type-checkers now?

#43

Post by KolmogorovComp » Mon, Jun 08, 2026, 3:34 PM UTC

Why anyone would still use mypy besides legacy infrastructure is beyond me. It is dog slow as well as being the laziest of all, not catching many mistakes.

Unfortunately for Django apps switching to any alternative leads to the dreaded “wall of errors” issue. If anyone got to work this out in the past, I’d gladly take advices.

Re: Are you expected to run five Python type-checkers now?

#44

Post by shevy-java » Mon, Jun 08, 2026, 3:35 PM UTC

The type-lovers will be angry! :)

The blog entry fits into ruby too, to some extent; while the situation is nowhear near as bad as in python, you have the same question-marks why types suddenly emerge out of nowhere. Almost ... almost as if some people have a specific agenda, and try to pull through with it.

Well, there you have it - the type-addicted people are ruining python.

Re: Are you expected to run five Python type-checkers now?

#45

Post by anamexis » Mon, Jun 08, 2026, 3:36 PM UTC

Tade0 wrote: post #28

pmontra wrote: post #23

Earlier quoted context omitted.

Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.

Personally I like having my TypeScript cake and eating it. I also truly believe those who design type systems would benefit from taking a look what kind of code people programming in dynamically-typed languages produce.

I do too, but I feel like TypeScript stands alone as an unusually effective and pleasant to use bolted-on type system. I've not seen any other approach come close. (My sample size is Python, Ruby and Elixir)

Re: Are you expected to run five Python type-checkers now?

#46

Post by prodigycorp » Mon, Jun 08, 2026, 3:37 PM UTC

what are ppls' impression of pyrefly? i've become completely captive to uv's tooling. it has allowed me to think only about coding versus tooling. dont feel like giving another typechecker a chance unless it offer's something i'm not getting from ty.

Re: Are you expected to run five Python type-checkers now?

#47

Post by locknitpicker » Mon, Jun 08, 2026, 3:37 PM UTC

dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

> If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

I don't understand your question. The whole point of static code analysis is preventing bugs. Don't you like Python code to not have bugs that are easily caught with static code analysis, or is preventing code a foreign idea that is better left to other languages?

Re: Are you expected to run five Python type-checkers now?

#48

Post by ForHackernews » Mon, Jun 08, 2026, 3:38 PM UTC

Someone wrote: post #33

ghostly_s wrote: post #30

Why would users care if you're using the same type checker as them? Surely they're not expecting all their imports to be instrumented for running redundant types checks?

Users do not care about that, but they want to not see type errors or warnings when they integrate your API in their code. That’s why you want to run their type checker on your API. you cannot know what “their type checker” is, so you want to run all popular type checkers on your API.

Sounds like a them-problem. Their type checker can accept my declared typings for my public API, or they can override it with their own custom type stubs if they have objections.

Re: Are you expected to run five Python type-checkers now?

#49

Post by shevy-java » Mon, Jun 08, 2026, 3:38 PM UTC

pmontra wrote: post #23

dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.

I am totally with you and I am glad I am not the only one who is totally against those type-addictions leaking into languages that did not need them in the first place.

Types in ruby are even worse than in python, because the type systems in use really make ruby turn very ugly. In python it is not as much as a huge problem with regards to syntax, as python has a stricter syntax (e. g. mandating foo.bar() whereas in ruby you can typically omit the (), among other syntax sugar examples).

We need to keep the type people out of those languages.

Many years ago, on IRC, on #haskell, they said they don't want everyone to use Haskell. Back then I did not understand it. After the type-addicted people emerged out of nowhere, I now begin to understand why Haskell is so snobbish. If you let every idea float, you end up ruining languages - and then those who wanted this, will retire and move away too. Ultimate damage factor caused as outcome here.

Re: Are you expected to run five Python type-checkers now?

#50

Post by locknitpicker » Mon, Jun 08, 2026, 3:39 PM UTC

fg137 wrote: post #31

ocamoss wrote: post #16

Earlier quoted context omitted.

Running more type checkers isn't really about strictness. The main benefit to library maintainers is to make sure that their APIs are compatible with whatever tools their users run. This wouldn't really be an issue for most other languages, but Python's typing ecosystem is uniquely fragmented, with only partial standardization between several popular tools.

Hmm... that doesn't answer the question?

> Hmm... that doesn't answer the question?

GP's point is obvious: performance is immaterial to the discussion. Static code analysis is about preventing bugs. Therefore OP fails to make any sort of point, as it's a straw man argument.