fix: finfo_object, iinfo_object, _array to typing.Protocol

[34j]

Closes #856

[rgommers]

@34j thanks a lot for working on improving static typing. Did you see gh-589 though? This PR seems to reinvent parts of that PR. It's nontrivial to review a large PR and get static typing right, but I prefer to push gh-589 forward if there is energy for that. Would you be interested in checking if that addresses your issue and needs?

[34j]

@rgommers
Yes, I noticed it an hour ago. I think it is now almost upwardly superior to #589 thanks to @nstarman in that all classes are protocols, with some changes.
I thought stopping the use of Optional and Union should be done by other PRs, so this PR does not incorporate those changes.

[lucascolley]

@jorenham you may have opinions on the activity here

[jorenham]

@jorenham you may have opinions on the activity here

I certainly do. But before I share them, would you mind telling me what the exact purpose is of these "stubs" (which usually refer to .pyi files)?

[lucascolley]

what the exact purpose is of these "stubs" (which usually refer to .pyi files)?

Not sure about the exact purpose, but they aren't (just) type stubs - they're primarily for housing the (sort of typed) signatures and docstrings from which the docs pages for individual functions are generated. I suppose they are "stubs" in the sense of having no function implementations.

[jorenham]

Not sure about the exact purpose

Then I think that the first step should be to figure that out, and document it.
If you don't know what you are building, then my typing-related opinions will all be based on baseless assumptions and personal preferences, which probably won't be very helpful.
So the only rational opinion I can give you at this point, is that I think that you should at least be able to answer the following questions:

• Will it be used as a verification suite for the static type annotations of array-api libraries?
• Will there be a "baseline" package that these protocols should at least be compatible with, e.g. numpy?
• Should it follow the official python typing specification, and if so, how will that be verified?
• Will it be distributed as a (standalone- or bundled-) package, and if so, should these types also be usable at runtime?

[lucascolley]

If you don't know what you are building, then my typing-related opinions will all be based on baseless assumptions and personal preferences, which probably won't be very helpful.

Disclaimer: I'm sure the array API maintainers 'know what they are building' - I've contributed to the repo, but not majorly.

[34j]

Perhaps the maintainers are mostly interested in discussing the contents of array-api and this may not be so important.

However, I have noticed a number of issues while working on this implementation and the #858 implementation, and would like to offer some observations.

• [no-protocol] Frequently abuses TypeVar, as there are so many functions that do not use TypeVar for both arguments and return values; TypeVar could be used correctly (only) if Generic Protocol is used, however according to Array namespace #685 (comment), this has been suspended because it was Protocol is "harder to understand".
  The work that should be done depends on whether the people “difficult to understand” Protocols includes the contributors to this repository.
  • If the contributors can understand the protocol, protocol-based implementation should be done in this repository (the content should be uploaded to PyPI) and then the ci could automatically generate function code and upload them to another “starter” repository.
  • Otherwise, vise versa. (feat: automatically generate Protocol for array-api-namespace #858)
• [no-separation] If this is the starting point for creating an array-api compatible library, it is bad that the mysterious TypeVars and _type.py with unknown Protocols are included and that no sub-modules other than linalg,fft are hidden (does not have _ prefix unlike array-api-strict). The repository should be split using automatic code generation, preferably as a “template” and stub package for developing array-api.
• [no-ellipsis] Ellipsis should be added if there is no internal implementation of the function.
• [no-pypi] Again, since array-api is not uploaded to PyPI, it cannot be used as a stub package or to check if a library is array-api compatible.
• [pre-commit] pre-commit is not set up properly, making it hard to develop; pyupgrade (for Python3.9+ typing like list[str]) and ruff (or autoflake and isort) should be added.
  
  https://github.com/asottile/pyupgrade?tab=readme-ov-file#pep-585-typing-rewrites

Thanks for taking a look anyway