delta/python-packages/numpy.git - github.com: numpy/numpy.git

	Commit message (Collapse)	Author	Age	Files	Lines
*	MAINT: Split `numpy.typing` into a public and private component	Bas van Beek	2022-03-18	1	-6/+0
\| \| \| \|	i.e. `numpy.typing` and `numpy._typing`
*	MAINT: Drop .py code-paths specific to Python 3.7	Bas van Beek	2021-08-30	1	-11/+1
\|
*	REV,BUG: Replace `NotImplemented` with `typing.Any`	Bas van Beek	2021-06-05	1	-2/+2
\|
*	ENH: Add a global constant to `numpy.typing` denoting whether or not ↵	Bas van Beek	2021-05-27	1	-4/+5
\| \| \| \|	`typing_extensions` is available
*	MAINT: Relax the integer-type-constraint of `npt._ShapeLike`	Bas van Beek	2021-04-14	1	-1/+10
\| \| \| \|	Change `int` into the more forgiving `SupportsIndex` protocol
*	MAINT: make typing module available at runtime	Josh Wilson	2020-06-09	1	-0/+6
	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.