8000 Add type hinting for numeric.py by johanvergeer · Pull Request #38 · numpy/numpy-stubs · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Jun 10, 2020. It is now read-only.

Add type hinting for numeric.py #38

Merged
merged 6 commits into from
Jan 14, 2020
Merged

Add type hinting for numeric.py #38

merged 6 commits into from
Jan 14, 2020

Conversation

johanvergeer
Copy link
Contributor

No description provided.

@johanvergeer
Copy link
Contributor Author

I have to add the tests for this file, but I first wanted to get your opinion.

shoyer
shoyer reviewed Nov 25, 2019
View reviewed changes
numpy-stubs/__init__.pyi Outdated
int,
float,
bool,
object,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a meaningful difference between TypeVar("_ArrayLike"), TypeVar("_ArrayLike", object) and what you wrote here?

I agree that it's a good idea to clearly identify "array like" arguments, but I'm not certain this the right annotation. Note that in most cases NumPy is fine with absolutely any type of object in cases where it needs an "array like" argument

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have a good point. I was already hesitating on how to create this TypeVar, but since an array_like can be just about anything, it makes better sense to just declare it as _ArrayLike = TypeVar("_ArrayLike")

Best thing is, we can always change this TypeVar if we come to another solution.

@aldanor
Copy link
aldanor commented Jan 14, 2020

Any plans on merging this?

@shoyer shoyer merged commit f3c6315 into numpy:master Jan 14, 2020
@shoyer
Copy link
Member
shoyer commented Jan 14, 2020

Apologies for the delays here. It would be great to get someone else who is excited about type checking with NumPy involved in maintaining this repository -- right now it is easy for notifications to get lost since activity is relatively low. Alternatively, maybe now is finally the time to move annotations into NumPy proper?

@johanvergeer
Copy link
Contributor Author

Hi @shoyer

I didn't continue to work on it because of the slow responses.
If we can start to add Mypy directly into Numpy I'm happy to help.

person142 added a commit to person142/numpy-stubs that referenced this pull request Apr 11, 2020
@person142
MAINT: move things in numeric.pyi to the top-level __init__.pyi
de558ff 
In numpygh-38 some stubs were added for `core/numeric.py`. The problem is
that these stubs are not picked up at all, however, 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`.

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
````
person142 added a commit to person142/numpy-stubs that referenced this pull request Apr 11, 2020
@person142
MAINT: move things in numeric.pyi to the top-level __init__.pyi
7f631d5 
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`.

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
````
@person142 person142 mentioned this pull request Apr 11, 2020
Merged
person142 added a commit to person142/numpy-stubs that referenced this pull request Apr 12, 2020
@person142
MAINT: move things in numeric.pyi to th C7B1 e top-level __init__.pyi
6fa10d8 
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
````
person142 added a commit to person142/numpy-stubs that referenced this pull request Apr 12, 2020
@person142
MAINT: move things in numeric.pyi to the top-level __init__.pyi
b41054f 
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
````
rgommers pushed a commit that referenced this pull request Apr 14, 2020
@person142
MAINT: move things in numeric.pyi to the top-level __init__.pyi (#50
f335f16 
)

In gh-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
````
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@shoyer shoyer shoyer left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@johanvergeer @aldanor @shoyer
0