> "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

▲ vitamark 2 hours ago | parent | next [-]

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

▲ samsartor 2 hours ago | parent | prev | next [-]

Elementwise equality! Given two dataframe columns or ndarrays, users often expect `==` to give out a column or ndarrays of bools (like `+`, ``, `*, `&`, and just about every other binary operator).

▲ olooney 2 hours ago | parent | prev | next [-]

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.

▲ datsci_est_2015 2 hours ago | parent | prev | next [-]

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)

▲

voidUpdate 2 hours ago | parent [-]

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"?

	▲	agons 34 minutes ago \| parent \| next [-]
		The first use case that comes to mind is if you want a DSL to build expressions that are evaluated later in some different context e.g. when using `polars`: ```python df.filter( pl.col("foo") == pl.col("bar"), ) ``` Sqlalchemy does something equivalent too, and I'm sure there are many others.
	▲	datsci_est_2015 2 hours ago \| parent \| prev [-]
		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

▲ kuschku 41 minutes ago | parent | prev | next [-]

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

▲ xemdetia 2 hours ago | parent | prev | next [-]

I thought JavaScript language equality quirks was seen as problematic not a missing feature in Python.

▲

voidUpdate 2 hours ago | parent | next [-]

At least in javascript, it tells you if things are equal or not. In python, apparently you could answer if A is equal to B with "beans" or 17 or ['a']

	▲	hmry an hour ago \| parent [-]
		Never understood this complaint about operator overloading. In any language, a function called `isEqual` could wipe your hard drive and replace your wallpaper with a photo of a penguin. Therefore, letting programmers pick the names of their functions is bad? No, obviously naming things for least surprise is the programmer's responsibility. But when it's the symbols `==` instead of an ASCII name, it's a problem in language design? (FWIW in Javascript, being unable to override == is actually a problem when you want to use objects as Map keys)

▲

throwaway894345 an hour ago | parent | prev [-]

Python never met a footgun it didn’t need to adopt. In this case, however, it’s not equality checks, but operator overloading. I was a Python developer for a decade before switching to Go and life on this side is so much better.

	▲	data-ottawa 42 minutes ago \| parent [-]
		Operator overloading has never been an issue for me, but terminating a line with a comma creating a tuple, or white space (including new lines) between strings to concatenate have cost me days of work over the years. I understand why those exist, but they’re pure evil.

▲ throwaway894345 an hour ago | parent | prev [-]

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