What's the use-case of this one? Is there anything this can help with, that HasShape can't?
Put differently; should we make this public API or not?

Shouldn't we have Protocols for all attributes in the Array API?

I don't see why we should write a protocol if there's no use for it.

ok, and what would you use that for in a real-world scenario

IDK personally, but the Array API is pretty sparing.
I could see using something like:

def check_min_size(obj: object) -> bool:
    if not is_sized(obj) or obj.size is None:
        raise Exception
    return obj.size > 10

Hm yea I guess, but that's probably pretty niche, right?

I guess I just feel like we should first start with fixing the big typing problems that the array-api libs are facing, and I don't consider this to be one of those. That's why I opened #22, so that we can get a better understanding of what those problems actually are. And right now it just feels like we're trying to mimick the runtime API, and blindly hope that it will somehow be helpful, without knowing how exactly.

Not disagreeing that there are other big issues to solve, but people also want and need the more straightforward static Array API. I've had many people ask me about doing straightforward things like

def square[T=Array](x: T) -> T: ...

So yeah, I do think there's a lot of value in starting to fill out the static equivalent to the runtime API.
We know it will be useful. And how.

Yes, for square specifically they should annotate this with some form of CanMul. But as we've been discussing in #32 writing this type is non-trivial and array_api_typing should probably be the space where we vendor something like

NumArrayCanMul = CanMulSelf[..., ...]  # fills in the complex types
BoolArrayCanMul = CanMulSelf[..., ...]  # The bool considerations we discussed

so that higher-level functions that require many parts of the Array API can do

def main():
    x = xp.array(...)
    ...
    ... square(...)

This HasTranspose restricts this to 2d arrays

Does it? I don't know of any array object that doesn't have this method, regardless of the value's dimensionality.

.transpose() is only defined for 2d arrays, so we should expect array libs to follow that, and we should therefore expect there to be annotations like

class SomeArray[ShapeT, DTypeT]:
    # --snip--
    def transpose(self: SomeArray[Rank2, DTypeT]) -> SomeArray[Rank2, DTypeT]: ...

So a SomeArray[Rank1] won't be assignable to xpt.Array.

That sounds great.
It sounds like there are two interpretations of how this should be represented statically given the API spec: "The array instance must be two-dimensional. If the array instance is not two-dimensional, an error should be raised."

1. That it statically determines the shape. This focuses on the 1st sentence.

@property
def T(self: SomeArray[Rank2, DTypeT]) -> SomeArray[Rank2, DTypeT]: ...

2. that it shadow the runtime. This focuses on the 2nd sentence.

@overload @property
def T(self: SomeArray[Rank0 | Rank1, DTypeT]) -> Never: ...
@overload @property
def T(self: SomeArray[Rank2, DTypeT]) -> SomeArray[Rank2, DTypeT]: ...
@overload @property
def T(self: SomeArray[RankGE3, DTypeT]) -> Never: ...

(or if we don't have shape typing)

def T(self: SomeArray) -> SomeArray | Never: ...  # yes, the Never is ignored.

This was written more with the 2nd interpretation in mind, but I'm very happy to accept the 1st interpretation and remove T from the default Array object, so long as we still include some form of HasTranspose Protocol for people to use.
I do think there is then interesting discussion about that Protocol ....
Should we vendor 2 forms? one for each interpretation? That will help people when building their own intersection types.

Is there a situation where you'd wanna use HasNDim over e.g. HasShape? Otherwise we probably should keep this private, given that

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

If you're checking for the attribute ndim.
Not sure I'm understanding this comment. Ndim is in the Array API spec...

Well, my point is that I think we should only provide users with protocols that help them annotate their array-api code. Otherwise, it'll just be confusing for the users, and a waste of time for us.

Oh. As the Array API is the intersection of the array libraries, IMO pretty much everything is useful.

Yea of course, everything in the array-api is designed for a reason. But all of those reasons apply in the runtime world. And our goal is to provide an API for the static-typing world, which is but a shadow of the runtime one, where only a subset of the API has practical use.

That's true, I'm just not sure we could really know which of the specific methods are/aren't useful for people in every situation. I agree we get more control over what goes into Array, but shouldn't we provide a Protocol for each individual method and attribute?

but shouldn't we provide a Protocol for each individual method and attribute?

We're not a stub library, so no, I don't think we should.

We do need a stub library... Maybe that's the easier thing to do first.

We do need a stub library... Maybe that's the easier thing to do first.

Stub libraries only apply to individual libraries. Stub libraries also can't be overridden or something, so libraries that have other methods besides the one from the array-api won't be able to use it. So I don't see how that would work (even though I'm all about writing stubs, as you know)

True. I guess I mean a direct method-by-method set of Protocols for the array API, like is in this PR.
I know this is what many people want, as a baseline at the very least. IMO this is the place for it.