Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pyrefly.org

Post reply on HN
Print view View original

11–20 of 220 posts

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

#11

Post by vitamark »

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

There are examples like ORM query builders (something like `User.id == user_id` should not return a boolean, but rather some inspectable query part), multi-value comparisons (e.g. numpy arrays and views which could also be used as masks for indexing)

In general, when you get your hands on operator overloading you get a bunch of various quirky applications for each. Some dunder methods have strict runtime-level rules (e.g. __hash__ or __len__), some don't

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

#12

Post by cryptonym »

voidUpdate wrote: post #4
woeirua wrote: post #2

With agents it no longer makes sense to tie yourself to Python's archaic development experience. How many type checkers are there? Package managers? Don't even get me started on cross-platform deployment. Strongly typed, compiled languages have never been easier to use, and agents reap huge benefits from the tight feedback loop that the compiler provides. Moreover the benefits of the Python ecosystem are less signifi…

What about the several people worldwide who don't want to use LLMs to program?

They also "reap huge benefits from the tight feedback loop that the compiler provides".

When something is easier/requires less context, it tends to work well for both human and LLM.

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

#13

Post by olooney »

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

It could return a vector or a deferred expression? In polars, for example, operations on `pl.col` return `Expr` objects that are used to build queries, not immediately evaluated:

    df.filter(pl.col("status") == "active")
In numpy, `x == y` return a boolean vector of the same shape as x and y, comparing them element-wise.

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

#14

Post by datsci_est_2015 »

voidUpdate wrote: post #7
datsci_est_2015 wrote: post #5

Earlier quoted context omitted.

One example is if an and b are arrays (e.g. numpy arrays) it’s not unreasonable for dunder eq to return an array of booleans. Another example might be if you have a domain specific representation of equality (e.g. class Equality)

I can see the first one making sense, but why would you need a representation of equality other than "yes, these are equal" and "no, these are not equal"?

Well personally I’m not a fan of turning everything into an object, but if you have properties or methods that exist upon the concept of Equality you might want to encode directly onto a class. Maybe in a domain where “Equality” is an important concept, like mathematics or even something like accounting.

Could enable a different interface into approximate equality for floating point numbers: Equality.approximate(iota: float) -> bool

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

#16

Post by ocamoss »

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?

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.

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

#17

Post by blahgeek »

> Prioritise running as many type-checkers as possible on your test suite. Run at least one on your source code.

There are two types of tests: those that test against the public API, and those that test internal codes with various mocks and fakes. I think the vast majority of unit tests is the latter one, in which case the suggestion does not really make sense.

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

#19

Post by throwaway894345 »

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

IIRC, SQLAlchemy overloads this to return an object that represents an equality check in SQL. Because it was returning an object, it was always evaluating to True, because of another of Python’s footguns: truthiness/falsiness. This was a decade ago, and these particular footguns were not even remotely the biggest culprits in our bug backlogs (another honorable mention includes accidentally calling a sync function in an async context, causing timeouts in unrelated endpoints and leading to cascading system failure).
Post reply on HN