Populate various protocols

[NeilGirdhar]

Populate the protocols introduced by #20

This issue is required for the creation of TODOs. 😄

[krokosik]

There is an interesting community approach at https://github.com/34j/types-array-api
It has an autogen for array type stubs, which would be nice to implement, however, the generated codes uses Python 3.12 syntax for generic types, making it unusable in older Python versions.

There are also some issues, where np.ndarray is considered incompatible with the TArray type when casting: 34j/types-array-api#61.

Perhaps it would be beneficial to merge these two projects? @NeilGirdhar @34j

[NeilGirdhar]

@krokosik Oh I'm not in charge! Best to contact one the maintainers :) I know @jorenham had some ideas about not generating stubs.

[jorenham]

Perhaps it would be beneficial to merge these two projects?

We have tried working together on this before, but that didn't work out. See data-apis/array-api#863 (reply in thread) and #14 for context.

[krokosik]

Oh my, I see. Understandable

[krokosik]

What is the current stance on automatic stub generation?

[jorenham]

What is the current stance on automatic stub generation?

My stance is that protocols with many methods are not a good idea. Because for once thing, they're detrimental for type-checker performance when used in overloads. Another is that it's highly unlikely that the downstream array api library annotations will be compatible with them, and are therefore practically useless for them.
That being said, I'm sure that there are ways to apply code generation is a way that's more, erm, constructive. For example, it can be useful for exhaustive type-test generation, of which there are many examples in numtype (a library with experimental new typing stubs for numpy).