-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
ENH: Add an ndarray
typing protocol
#19752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
ndarray
typing protocol
I'm afraid there isn't, and considering the sheer size of such a protocol I'm a rather reluctant to add one. Interestingly, based on your examples it does sound like an intersection-type (xref python/typing#213) would resolve your issue, as this would allow you to describe an arbitrary class MethodProtocol(Protocol):
def method(self, input): ...
# expects an `ndarray` subclass that implements `method`
def operates_on_protocol(in: np.ndarray & MethodProtocol): ... |
If you are interested in the future array API standard maybe you can also take a look at this: |
Yeah, but until that is implemented, this was another approach I was considering.
Unfortunately, that doesn't nearly cover all the functions and capabilities of an @BvB93 Can the type annotations in the pyi files just be provided as a runtime_checkable Protocol rather than a regular class? That way there's not a redundant copy of the same interface and the current capabilities are still maintained. |
No, even if we ignore the fact that |
What I mean to suggest is to only change the annotation to a protocol, i.e., something like - class ndarray(_ArrayOrScalarCommon, Generic[_ShapeType, _DType_co]):
+ class ndarrayProtocol(_ArrayOrScalarCommon, Generic[_ShapeType, _DType_co], Protocol): and then have the actual Might also need to add: class ndarray(ndarrayProtocol[_ShapeType, _DType_co]): # <-- not a Protocol
pass or something to the same |
Honestly, I see little value in adding, exposing and maintaining such a massive protocol. The only use case were such protocol would be appropriate for the mixed nominal/structural subtyping you're trying to express here. And even this is more of band-aid solution necessitated by the lack of
Depending on the exact nature of these constraints, you could potentially define a type-check-only ABC and use that as baseclass. import abc
import numpy as np
from typing import TYPE_CHECKING
if TYPE_CHECKING:
class FakeABC(np.ndarray, metaclass=abc.ABCMeta):
@abc.abstractmethod
def method(self, input): ...
else:
FakeABC = np.ndarray
class ImpementsMethod(FakeABC):
def method(self, input): ,..
class AlsoImpementsMethod(FakeABC):
def method(self, input): ...
def operates_on_fake_abc(in: FakeABC): ... |
I'd like to define a protocol that extends the numpy N-D Array. I can't create an abstract base class for unrelated reasons. I'd like to do something like the following:
The protocol cannot subclass
ndarray
directly, so I need to use something likeNDArrayProtocol
. Is there an ndarray protocol exposed somewhere?The text was updated successfully, but these errors were encountered: