Skip to content

HUH: squeezeing scalars #30109

@jorenham

Description

@jorenham

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

Footnotes

  1. Is that a thing? Well, if it isn't; then I think it should.

  2. which, given the lack of comment about it, might just have been a "happy little accident" (🎨)

  3. they're technically not correct either, seeing as it can return Any

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions