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

Re:Are you expected to run five Python type-checkers now? by vitamark on Monday June 08, 2026 @10:33AM (#48445960)

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

[ Parent | on HN ]

Re:Are you expected to run five Python type-checkers now? by brandnewideas on Monday June 08, 2026 @05:23PM (#48452336)

That's one of the things I truly didn't get from my (very limited) experience with SQLAlchemy. Why not just have a method like orm.eq(User.id, user_id)? Much more readable.

[ Parent | on HN ]

Re:Are you expected to run five Python type-checkers now? by vitamark on Saturday June 13, 2026 @05:30AM (#48515286)

Probably just the convenience.

Expression `select(User).where(User.id == user_id)` does look simpler and cleaner than `select(User).where(eq(User.id, user_id)))`.

Maybe there is an actual eq function of sorts that allows that, and it's not a life-or-death difference here, but as far as convenience goes, it works well. And typecheckers are good enough to be able to let you know what's the return type.

[ Parent | on HN ]