🏷️ ufunc annotations for logical_{not,and,or,xor}

[guan404ming]

Towards #230

[guan404ming]

@jorenham I see the difference between them. Should I create a new class for the logical-related functions, or is there an existing class in the codebase that I might have missed? Just wondering if there's something already available before I go ahead with a new one. 😊

[jorenham]

@jorenham I see the difference between them. Should I create a new class for the logical-related functions, or is there an existing class in the codebase that I might have missed? Just wondering if there's something already available before I go ahead with a new one. 😊

I don't that there's anything like that in the numtype codebase yet. I also couldn't find anything salvageable for this in scipy-stubs (https://github.com/scipy/scipy-stubs/blob/master/scipy-stubs/special/_ufuncs.pyi).

Kudo's for your "don't reinvent the wheel" mindset, BTW 👌🏻

---

FYI, the default callable protocol includes a workaround for ->O cases like these:

numtype/src/numpy-stubs/_typing/_ufunc.pyi

Lines 837 to 846 in b827c82

	@overload
	def __call__(
	self,
	x1: ArrayLike,
	x2: ArrayLike,
	/,
	out: None = None,
	dtype: DTypeLike | None = None,
	**kwargs: Unpack[_Kwargs3],
	) -> _OutT_co | NDArray[np.object_]: ...

But that's a rather awkward solution that should only be seen as a "last-result fallback placeholder workaround default" thing (but this PR shows that I'm preaching to the choir).

[guan404ming]

Not kind of sure about the implementation if great or not. I try my best to handle all kind of situations~
Pls help me review merci @jorenham

[jorenham]

This is a pretty difficult signature to annotate, so it might take a couple of tries to get it right.

It's also no problem if you're not able to figure it out yet. So if that's the case then I wouldn't mind helping out here.

[guan404ming]

Here’s a simple note I learned from this discussion:

1. np.object_ doesn’t really exist as a scalar – it just returns the input type. It works as dtype=object in arrays, but not as a standalone type.
2. not _ always returns bool, so the return type should be bool, not np.object_.
3. Mypy has a bug that makes it hard to properly annotate np.object_behavior.
4. __array_ufunc__ can return anything 🦆
5. For dtype=np.object_, the return type should be NDArray[np.object_] | something you want, since np.object_ doesn’t work as a scalar.
6. Overloads should be ordered carefully, with more specific ones first.
7. DTypeLike adjustments are needed to avoid unwanted np.object_ inference.

Big thanks for the explanation! This is what I learned from u, and I noted it down so others can also share this knowledge. 🚀

merci @jorenham

[jorenham]

Good progress 💪🏻.

Here's the next iteration of comments, hopefully they make sense.

[guan404ming]

Updated~ Thanks for comments learn a lots

[guan404ming]

Oh sorry, my fault 🤦

[jorenham]

Almost there!

[guan404ming]

Big thanks again!

[jorenham]

I didn't notice this one before; sorry about that. But that one aside, I've got nothing to complain about anymore 👌🏻

[guan404ming]

Updated, thanks for helping out and taught me a lots!

[jorenham]

In it goes — Thanks Guan-Ming 🎉