-
-
Notifications
You must be signed in to change notification settings - Fork 11.7k
Description
I wasn't sure if this should be an "ENH", "BUG", "TYP", "DEP", or "MAINT", so I opted for the sound that came out of my mouth when I first encountered this. Feel free to change it to one of those if you feel like it.
This just made me "huh" out loud:
>>> np.squeeze(1)
array(1)
>>> np.squeeze(np.array(1))
array(1)
>>> np.squeeze(np.int_(1))
np.int64(1)So "scalar-likes" are not treated equally; some return numpy scalars, others return 0d arrays.
Besides this increasing the ever so important "huh/sec" rate 1, it's also pretty annoying to express in the stubs. But before you panick and/or call the press, the squeeze stubs aren't incorrect 2 3, so it's not that big of a disaster.
Anyway, given the array-api's lack of scalar-types, and them being infuriatingly annoying for static typing, I think that I'm slightly leaning towards choosing 0d-arrays over scalars here. I.e., changing squeeze so that it always returns an instance of numpy.ndarray (or a subtype thereof), even if you pass it a np.generic scalar-type thingy.
This would technically be a backwards-incompatible breaking change. But, considering that 0d arrays are mostly duck-type compatible, and that I don't see why anyone would want to squeeze their scalars in the first place, I doubt that many will be bothered by this change.
TLDR; Let's have numpy.squeeze always return an array