summaryrefslogtreecommitdiff
path: root/numpy/typing/_array_like.py
Commit message (Collapse)AuthorAgeFilesLines
* MAINT: Split `numpy.typing` into a public and private componentBas van Beek2022-03-181-143/+0
| | | | i.e. `numpy.typing` and `numpy._typing`
* MAINT: Create the `_ArrayLike` type-alias in `numpy.typing`Bas van Beek2022-01-241-0/+6
| | | | Represents a subset of `npt.ArrayLike` that can be parametrized w.r.t. `np.generic`
* MAINT: Rename the old `_ArrayLike` parameter used inside the `_array_like` ↵Bas van Beek2022-01-241-12/+12
| | | | module
* TYP: Add a protocol class representing `__array_function__`Bas van Beek2022-01-111-0/+14
|
* MAINT: Replace the old `_NestedSequence` union and remove `_RecursiveSequence`Bas van Beek2021-09-191-12/+21
|
* MAINT: Drop .py code-paths specific to Python 3.7Bas van Beek2021-08-301-18/+8
|
* MAINT: Remove unused imports and unreachable code (#18762)Elisha Hollander2021-07-071-3/+0
| | | * Remove unnecessary imports and minor fixes
* MAINT: Replace `"dtype[Any]"` with `dtype` in the definiton of `npt.ArrayLike`Bas van Beek2021-06-241-1/+1
| | | | | | Strings and types that are not subscriptable during runtime can cause issues with runtime Introspection helpers such as `typing.get_type_hints`. While this is very much an upstream issue, the particular case of `npt.ArrayLike` can be quite easily resolved in numpy.
* MAINT: Added a missing `sys.version` checkBas van Beek2021-06-051-1/+1
|
* REV,BUG: Replace `NotImplemented` with `typing.Any`Bas van Beek2021-06-051-2/+2
|
* ENH: Add a global constant to `numpy.typing` denoting whether or not ↵Bas van Beek2021-05-271-9/+6
| | | | `typing_extensions` is available
* MAINT: removed unused imports listed in LGTMdefault-3032021-05-241-2/+1
|
* MAINT: Replace `_ArrayND` with `NDArray`Bas van Beek2021-05-121-5/+0
|
* MAINT: Remove the `np.typing._ArrayOrScalar` type-aliasBas van Beek2021-04-301-2/+0
|
* MAINT: Relax the signature of the `__array__` protocolBas van Beek2021-03-121-2/+3
| | | | Implementations of `__array__` do not require the `dtype` parameter
* MAINT: Added the `_ArrayLikeInt` type aliasBas van Beek2021-02-251-0/+5
| | | | | An invariant-ish array-like consisting of int-like objects. Note that it is not truly invariant due to `builtins.bool` inheriting from `builtins.int`
* ENH: Add dtype support to the array comparison ops (#18128)Bas van Beek2021-01-211-2/+16
| | | | | | | | | | | | | | | | | | | | | * ENH: Added `_ArrayLikeNumber` * ENH: Added dtype support to the array comparison ops * MAINT: Made `dtype` and `ndarray` covariant The dtypes scalar-type and ndarrays' dtype are now covariant instead of invariant. This change is necasary in order to ensure that all generic subclasses can be used as underlying scalar type. * TST: Updated the comparison typing tests * MAINT: Fixed an issue where certain `array > arraylike` operations where neglected More specifically operations between array-likes of `timedelta64` and `ndarray`s that can be cast into `timedelta64`. For example: ar_i = np.array([1]) seq_m = [np.timedelta64()] ar_i > seq_m
* MAINT: Renamed `_ArrayLike<X>` to `_ArrayLike<X>_co`Bas van Beek2021-01-181-12/+12
|
* MAINT: Add aliases for commonly used `ArrayLike` objectsBas van Beek2020-12-211-6/+79
|
* STY: Fixed a typo: `ofthe` -> `of the`Bas van Beek2020-12-111-1/+1
| | | | | | Addresses https://github.com/numpy/numpy/pull/17981#discussion_r541018879 Co-Authored-By: Charles Harris <charlesr.harris@gmail.com>
* ENH: Add dtype-support for the `__array__` protocolBas van Beek2020-12-111-8/+13
|
* MAINT: Rename `DtypeLike` to `DTypeLike`Bas van Beek2020-11-031-3/+3
|
* MAINT: Move aliases for common scalar unions to `numpy.typing` (#17429)Bas van Beek2020-10-071-1/+7
| | | * MAINT: Move the `<scalar>Like` unions to `numpy.typing`
* DOC: add reference to Python issue about buffer protocolsJosh Wilson2020-06-161-2/+4
|
* DOC: add note about supporting buffer protocols in `ArrayLike`Josh Wilson2020-06-151-0/+5
|
* DOC: add warning about typing-extensions module to numpy.typing docsJosh Wilson2020-06-111-2/+2
| | | | | | Typing `ArrayLike` correctly relies on `Protocol`, so warn users that they should be on 3.8+ or install `typing-extensions` if they want everything to work as expected.
* MAINT: make typing module available at runtimeJosh Wilson2020-06-091-0/+27
Closes https://github.com/numpy/numpy/issues/16550. This makes `np.typing.ArrayLike` and `np.typing.DtypeLike` available at runtime in addition to typing time. Some things to consider: - `ArrayLike` uses protocols, which are only in the standard library in 3.8+, but are backported in `typing_extensions`. This conditionally imports `Protocol` and sets `_SupportsArray` to `Any` at runtime if the module is not available to prevent NumPy from having a hard dependency on `typing_extensions`. Since e.g. mypy already includes `typing_extensions` as a dependency, anybody actually doing type checking will have it set correctly. - We are starting to hit the edges of "the fiction of the stubs". In particular, they could just cram everything into `__init__.pyi` and ignore the real structure of NumPy. But now that typing is available a runtime, we have to e.g. carefully import `ndarray` from `numpy` in the typing module and not from `..core.multiarray`, because otherwise mypy will think you are talking about a different ndarray. We will probably need to do some shuffling the stubs into more fitting locations to mitigate weirdness like this.
View Lorry Controller Status