| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
i.e. `numpy.typing` and `numpy._typing`
|
| |
|
|
|
|
|
|
| |
Adding this special hook file tells PyInstaller what files a self contained
NumPy application needs to run. A test is included to verify that the hook still
finds all necessary files.
Closes #17184.
|
| |
|
|
|
|
|
| |
Instead of the leading underscore, the experimentalness of the module will be
indicated by omitting a warning on import. That we, we do not have to change
the API from underscore to no underscore when the module is no longer
experimental.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the type stubs and tests from numpy-stubs. Things this entails:
- Copy over the stubs (numpy/__init__.pyi and
numpy/core/_internal.pyi)
- The only modification made was removing `ndarray.tostring` since
it is deprecated
- Update some setup.py files to include pyi files
- Move the tests from numpy-stubs/tests into numpy/tests
- Skip them if mypy is not installed (planning on setting up CI in a
future PR)
- Add a mypy.ini; use it to configure mypy in the tests
- It tells mypy where to find NumPy in the test env
- It ignores internal NumPy type errors (since we only want to
consider errors from the tests cases)
- Some small edits were made to fix test cases that were emitting
deprecation warnings
- Add numpy/py.typed so that the types are picked up in an
installed version of NumPy
|
| | |
|
| |
|
|
| |
Signed-off-by: Changqing Li <changqing.li@windriver.com>
|
| |
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
| |
|
|
|
| |
Bento builds are no longer supported, so remove references to that
built system.
|
| |
|
|
|
| |
This fixes the distutils built from an sdist (e.g. under tox),
without including _build_utils in binary distributions or the installed numpy.
|
| |
|
|
| |
The intention is to make it easier to spot missing items
|
| |
|
|
|
|
|
|
|
|
|
| |
The sub-package is already included in bento builds, it appears
to have been missed from distutils.
This fixes the following error whilst running any tests with tox
```
ImportError: No module named build_utils.apple_accelerate
```
|
| |
|
|
|
| |
This covers those locations that either import or build numarray
or numeric.
|
| |
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New modules chebyshev and polynomial are added. The new polynomial module
is not compatible with the current polynomial support in numpy, but is much
like the new chebyshev module. The most noticeable difference to most will
be that coefficients are specified from low to high power, that the low
level functions do *not* accept the Chebyshev and Polynomial classes as
arguements, and that the Chebyshev and Polynomial classes include a domain.
Mapping between domains is a linear substitution and the two classes can be
converted one to the other, allowing, for instance, a Chebyshev series in
one domain to be expanded as a polynomial in another domain.
The new modules are not automatically imported into the numpy namespace,
they must be explicitly brought in with a "import numpy.polynomial"
statement.
|
| | |
|
| |
|
|
|
| |
I forgot to commit the name change suggested by Stefan. You need to
clean build/install directory when updating to this version.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
using the oldnumeric interface.
|
| | |
|
| | |
|
| |
|
|
| |
module and numpy does not contain all of the names.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
