For static type-checking purposes it would help if the typing stubs would also reflect this change

I think this is fine, but it should work by converting to an array via normal asarray() logic? I.e. flat defines __array__().

@seberg The stubs require it to be a integer Sequence or an integer ndarray at the moment (for multi-indexing), i.e. SupportsArray isn't included 🤔

I am saying that we shouldn't implement arr.flat speficically, but if we do that implement any integer array-like just like normal indexing.

I don't have a problem with the extra PyArrayIter_Check in the fast path, that should just be a pointer comparison in the common case I think.

I am saying that we shouldn't implement arr.flat speficically, but if we do that implement any integer array-like just like normal indexing.

Does this mean that we should not do the if PyArrayIter_Check, and instead try to do PyArray_FROM_O when we fall through the rest of the cases?

Something like that. The best thing may be to just call the normal indexing preparation code to ensure we do the same thing. Not sure if that works, but I suspect it will.
It would probably mean we also allow arr.flat[0,], but that seems fine also?

Something like that. The best thing may be to just call the normal indexing preparation code to ensure we do the same thing. Not sure if that works, but I suspect it will. It would probably mean we also allow arr.flat[0,], but that seems fine also?

Yeah, that seems like a more involved fix however, since the whole iter_subscript routine will have to be adjusted, right? I'll have a look at it tomorrow.

No, not a complete adjustment hopefully, you would call:

No, not a complete adjustment hopefully, you would call:

numpy/numpy/_core/src/multiarray/mapping.c

Line 277 in cc9f8aa

prepare_index(PyArrayObject *self, PyObject *index,

and then need to use the result of that. But after it, you don't have to deal with conversion anymore.

Would we use prepare_index with self->ao where self is the array iter object? That seems wrong since it's more than possible for the array iter object and the underlying array to not have the same dimensionality.

Hmmm, True, so it might not actually work without changes. It may be that all it needs from the array is the number of dimensions, but not sure.

I gave this a try, but I'm too unfamiliar with this part of the codebase so I didn't have much progress. Maybe it'd be okay for this to go in as-is (after I've added some more tests) and open a follow-up issue to rework iter_subscript in general?

Friendly ping.

Well, I can see that re-using mapping.c is too much hassle/not worthwhile. But I still think that this can be more generic and just cast to array generally (i.e. be merged with the previous branch).
In prepare_index that happens here:

The only reason not to do that, is that it would fix currently broken cases like:

• arr.flat[[True, True]] (incorrectly behaves like arr.flat[[1, 1]])
• arr.flat[[0.0, 1.0]] (should just fail)

Which means you can convince me that we don't need to merge it, but I think only if we allow doing it in the future (and deprecate/warn about those).
But it is likely just as easy to add the special path afterwards (i.e. if input was a list, warn and force cast).

We looked at this in a triage meeting and would like to see this handle more general array types as @seberg says just above. @lysnikolaou what do you think?

Thanks for the update @mattip and sorry for taking so long to reply here. I'll spend some time on this this week to hopefully get it over the finish line.

Hey folks! Sorry for the delay here, but I came back to this today and I just pushed a commit that I think is closer to what we want.

EDIT: Deleted a question that I didn't think through. Answer is clear to me now.

Gentle ping on this, in case anyone has some spare cycles for a review.

Thanks @lysnikolaou! Could you open the followup issue to track further improvements to flat when you have a chance?