This repository was archived by the owner on Jun 10, 2020. It is now read-only.
8000
MAINT: move things in
MAINT: move things in numeric.pyi to the top-level __init__.pyi
#50
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Note that these functions still have no tests (which is how this didn't get caught originally); I didn't try to fix that in this PR. |
person142
commented
Apr 11, 2020
| ) -> _ArrayLike: ... | ||
| def array_equal(a1: _ArrayLike, a2: _ArrayLike) -> bool: ... | ||
| def array_equiv(a1: _ArrayLike, a2: _ArrayLike) -> bool: ... | ||
| def extend_all(module: ModuleType): ... |
There was a problem hiding this comment.
This isn't a public function, so I removed it.
person142
commented
Apr 11, 2020
| axis: Optional[Union[int, Tuple[int, ...]]] = ..., | ||
| ) -> _T: ... | ||
| def rollaxis(a: _ArrayLike, axis: int, start: int = ...) -> ndarray: ... | ||
| def normalize_axis_tuple( |
There was a problem hiding this comment.
Not a public function; removed it.
person142
commented
Apr 11, 2020
| subok: bool = ..., | ||
| shape: Optional[Union[int, Sequence[int]]] = ..., | ||
| ) -> ndarray[int]: ... | ||
| def ones( |
There was a problem hiding this comment.
Already defined in __init__.pyi.
person142
commented
Apr 11, 2020
| order: str = ..., | ||
| subok: bool = ..., | ||
| shape: Optional[Union[int, Sequence[int]]] = ..., | ||
| ) -> ndarray[int]: ... |
There was a problem hiding this comment.
Converted the various ndarray[T] things to ndarray, since that's not a thing yet (#48).
makes sense to me |
7f631d5 to
6fa10d8
Compare
In numpygh-38 some stubs were added for `core/numeric.py`. The problem is that these stubs are not picked up at all, as can be tested with ```python import numpy as np reveal_type(np.ones_like) ``` which on master gives ``` Revealed type is 'Any' ``` The issue is that the NumPy main repo importing from numeric doesn't automatically mean the type stubs do. We could add the relevant imports on the stubs level too, but there is no need for the structure of the stubs to mimic the structure of NumPy unless they are being used to type-check NumPy itself (which we aren't doing yet), and indeed having them mimic the internal structure just causes extra pain of trying to keep up with internal refactors that don't affect the public API. In fact, we already ignore NumPy's internal structure by defining `ndarray` in the top-level `__init__.pyi`, when it is actually exported by `numeric.py`. So instead, just fix the issue by moving the numeric stubs into the top level `__init__.pyi` (plus some minor bug fixes). On master the above script now correctly gives: ``` Revealed type is 'def [_ArrayLike] (a: _ArrayLike`-1, dtype: Union[numpy.dtype, None] =, order: builtins.str =, subok: builtins.bool =, shape: Union[builtins.int, typing.Sequence[builtins.int], None] =) -> numpy.ndarray ````
6fa10d8 to
b41054f
Compare
|
Ok, fixed the pyflakes error. |
|
LGTM, merged. Thanks @person142 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In gh-38 some stubs were added for
core/numeric.py. The problem isthat these stubs are not picked up at all, as can be tested with
which on master gives
The issue is that the NumPy main repo importing from numeric doesn't
automatically mean the type stubs do. We could add the relevant
imports on the stubs level too, but there is no need for the structure
of the stubs to mimic the structure of NumPy unless they are being
used to type-check NumPy itself (which we aren't doing yet), and
indeed having them mimic the internal structure just causes extra pain
of trying to keep up with internal refactors that don't affect the
public API. In fact, we already ignore NumPy's internal structure by
defining
ndarrayin the top-level__init__.pyi, when it isactually exported by
numeric.So instead, just fix the issue by moving the numeric stubs into the
top level
__init__.pyi(plus some minor bug fixes). On master theabove script now correctly gives: