NumPy 1.21.0 Release Notes
The NumPy 1.21.0 release highlights are
 continued SIMD work covering more functions and platforms,
 initial work on the new dtype infrastructure and casting,
 universal2 wheels for Python 3.8 and Python 3.9 on Mac,
 improved documentation,
 improved annotations,
 new
PCG64DXSM
bitgenerator for random numbers.
In addition there are the usual large number of bug fixes and other
improvements.
The Python versions supported for this release are 3.73.9. Official
support for Python 3.10 will be added when it is released.
New functions
Add PCG64DXSM BitGenerator
Uses of the PCG64 BitGenerator in a massivelyparallel context have
been shown to have statistical weaknesses that were not apparent at the
first release in numpy 1.17. Most users will never observe this weakness
and are safe to continue to use PCG64. We have introduced a new
PCG64DXSM BitGenerator that will eventually become the new default
BitGenerator implementation used by default_rng
in future releases.
PCG64DXSM solves the statistical weakness while preserving the
performance and the features of PCG64.
See upgradingpcg64
for more details.
(gh18906)
Expired deprecations

The
shape
argumentnumpy.unravel_index
cannot be
passed asdims
keyword argument anymore. (Was deprecated in NumPy
1.16.)(gh17900)

The function
PyUFunc_GenericFunction
has been disabled. It was
deprecated in NumPy 1.19. Users should call the ufunc directly using
the Python API.(gh18697)

The function
PyUFunc_SetUsesArraysAsData
has been disabled. It was
deprecated in NumPy 1.19.(gh18697)

The class
PolyBase
has been removed (deprecated in numpy 1.9.0).
Please use the abstractABCPolyBase
class instead.(gh18963)

The unused
PolyError
andPolyDomainError
exceptions are removed.(gh18963)
Deprecations
Inexact matches for numpy.convolve
and numpy.correlate
are deprecated
numpy.convolve
and numpy.correlate
now
emit a warning when there are case insensitive and/or inexact matches
found for mode
argument in the functions. Pass full "same"
,
"valid"
, "full"
strings instead of "s"
, "v"
, "f"
for the
mode
argument.
(gh17492)
np.typeDict
has been formally deprecated
np.typeDict
is a deprecated alias for np.sctypeDict
and has been so
for over 14 years
(6689502).
A deprecation warning will now be issued whenever getting np.typeDict
.
(gh17586)
Exceptions will be raised during arraylike creation
When an object raised an exception during access of the special
attributes __array__
or __array_interface__
, this exception was
usually ignored. A warning is now given when the exception is anything
but AttributeError. To silence the warning, the type raising the
exception has to be adapted to raise an AttributeError
.
(gh19001)
Four ndarray.ctypes
methods have been deprecated
Four methods of the ndarray.ctypes
object have been
deprecated, as they are (undocumentated) implementation artifacts of
their respective properties.
The methods in question are:
_ctypes.get_data
(use_ctypes.data
instead)_ctypes.get_shape
(use_ctypes.shape
instead)_ctypes.get_strides
(use_ctypes.strides
instead)_ctypes.get_as_parameter
(use_ctypes._as_parameter_
instead)
(gh19031)
Expired deprecations

The
shape
argumentnumpy.unravel_index
] cannot be
passed asdims
keyword argument anymore. (Was deprecated in NumPy
1.16.)(gh17900)

The function
PyUFunc_GenericFunction
has been disabled. It was
deprecated in NumPy 1.19. Users should call the ufunc directly using
the Python API.(gh18697)

The function
PyUFunc_SetUsesArraysAsData
has been disabled. It was
deprecated in NumPy 1.19.(gh18697)
Remove deprecated PolyBase
and unused PolyError
and PolyDomainError
The class PolyBase
has been removed (deprecated in numpy 1.9.0).
Please use the abstract ABCPolyBase
class instead.
Furthermore, the unused PolyError
and PolyDomainError
exceptions are
removed from the numpy.polynomial
.
(gh18963)
Compatibility notes
Error type changes in universal functions
The universal functions may now raise different errors on invalid input
in some cases. The main changes should be that a RuntimeError
was
replaced with a more fitting TypeError
. When multiple errors were
present in the same call, NumPy may now raise a different one.
(gh15271)
__array_ufunc__
argument validation
NumPy will now partially validate arguments before calling
__array_ufunc__
. Previously, it was possible to pass on invalid
arguments (such as a nonexisting keyword argument) when dispatch was
known to occur.
(gh15271)
__array_ufunc__
and additional positional arguments
Previously, all positionally passed arguments were checked for
__array_ufunc__
support. In the case of reduce
, accumulate
, and
reduceat
all arguments may be passed by position. This means that when
they were passed by position, they could previously have been asked to
handle the ufunc call via __array_ufunc__
. Since this depended on the
way the arguments were passed (by position or by keyword), NumPy will
now only dispatch on the input and output array. For example, NumPy will
never dispatch on the where
array in a reduction such as
np.add.reduce
.
(gh15271)
Validate input values in Generator.uniform
Checked that high  low >= 0
in np.random.Generator.uniform
. Raises
ValueError
if low > high
. Previously outoforder inputs were
accepted and silently swapped, so that if low > high
, the value
generated was high + (low  high) * random()
.
(gh17921)
/usr/include
removed from default include paths
The default include paths when building a package with numpy.distutils
no longer include /usr/include
. This path is normally added by the
compiler, and hardcoding it can be problematic. In case this causes a
problem, please open an issue. A workaround is documented in PR 18658.
(gh18658)
Changes to comparisons with dtype=...
When the dtype=
(or signature
) arguments to comparison ufuncs
(equal
, less
, etc.) is used, this will denote the desired output
dtype in the future. This means that:
np.equal(2, 3, dtype=object)
will give a FutureWarning
that it will return an object
array in the
future, which currently happens for:
np.equal(None, None, dtype=object)
due to the fact that np.array(None)
is already an object array. (This
also happens for some other dtypes.)
Since comparisons normally only return boolean arrays, providing any
other dtype will always raise an error in the future and give a
DeprecationWarning
now.
(gh18718)
Changes to dtype
and signature
arguments in ufuncs
The universal function arguments dtype
and signature
which are also
valid for reduction such as np.add.reduce
(which is the implementation
for np.sum
) will now issue a warning when the dtype
provided is not
a "basic" dtype.
NumPy almost always ignored metadata, byteorder or time units on these
inputs. NumPy will now always ignore it and raise an error if byteorder
or time unit changed. The following are the most important examples of
changes which will give the error. In some cases previously the
information stored was not ignored, in all of these an error is now
raised:
# Previously ignored the byteorder (affect if nonnative)
np.add(3, 5, dtype=">i32")
# The biggest impact is for timedelta or datetimes:
arr = np.arange(10, dtype="m8[s]")
# The examples always ignored the time unit "ns":
np.add(arr, arr, dtype="m8[ns]")
np.maximum.reduce(arr, dtype="m8[ns]")
# The following previously did use "ns" (as opposed to `arr.dtype`)
np.add(3, 5, dtype="m8[ns]") # Now return generic time units
np.maximum(arr, arr, dtype="m8[ns]") # Now returns "s" (from `arr`)
The same applies for functions like np.sum
which use these internally.
This change is necessary to achieve consistent handling within NumPy.
If you run into these, in most cases pass for example
dtype=np.timedelta64
which clearly denotes a general timedelta64
without any unit or byteorder defined. If you need to specify the
output dtype precisely, you may do so by either casting the inputs or
providing an output array using out=
.
NumPy may choose to allow providing an exact output dtype
here in the
future, which would be preceded by a FutureWarning
.
(gh18718)
Ufunc signature=...
and dtype=
generalization and casting
The behaviour for np.ufunc(1.0, 1.0, signature=...)
or
np.ufunc(1.0, 1.0, dtype=...)
can now yield different loops in 1.21
compared to 1.20 because of changes in promotion. When signature
was
previously used, the casting check on inputs was relaxed, which could
lead to downcasting inputs unsafely especially if combined with
casting="unsafe"
.
Casting is now guaranteed to be safe. If a signature is only partially
provided, for example using signature=("float64", None, None)
, this
could lead to no loop being found (an error). In that case, it is
necessary to provide the complete signature to enforce casting the
inputs. If dtype="float64"
is used or only outputs are set (e.g.
signature=(None, None, "float64")
the is unchanged. We expect that
very few users are affected by this change.
Further, the meaning of dtype="float64"
has been slightly modified and
now strictly enforces only the correct output (and not input) DTypes.
This means it is now always equivalent to:
signature=(None, None, "float64")
(If the ufunc has two inputs and one output). Since this could lead to
no loop being found in some cases, NumPy will normally also search for
the loop:
signature=("float64", "float64", "float64")
if the first search failed. In the future, this behaviour may be
customized to achieve the expected results for more complex ufuncs. (For
some universal functions such as np.ldexp
inputs can have different
DTypes.)
(gh18880)
Distutils forces strict floating point model on clang
NumPy distutils will now always add the ffpexceptionbehavior=strict
compiler flag when compiling with clang. Clang defaults to a nonstrict
version, which allows the compiler to generate code that does not set
floating point warnings/errors correctly.
(gh19049)
C API changes
Use of ufunc>type_resolver
and "type tuple"
NumPy now normalizes the "type tuple" argument to the type resolver
functions before calling it. Note that in the use of this type resolver
is legacy behaviour and NumPy will not do so when possible. Calling
ufunc>type_resolver
or PyUFunc_DefaultTypeResolver
is strongly
discouraged and will now enforce a normalized type tuple if done. Note
that this does not affect providing a type resolver, which is expected
to keep working in most circumstances. If you have an unexpected
usecase for calling the type resolver, please inform the NumPy
developers so that a solution can be found.
(gh18718)
New Features
Added a mypy plugin for handling platformspecific numpy.number
precisions
A mypy plugin is now available for
automatically assigning the (platformdependent) precisions of certain
numpy.number
subclasses, including the likes of
numpy.int_
, numpy.intp
and
numpy.longlong
. See the documentation on
scalar types <arrays.scalars.builtin>
for a comprehensive overview of the affected classes.
Note that while usage of the plugin is completely optional, without it
the precision of abovementioned classes will be inferred as
typing.Any
.
To enable the plugin, one must add it to their mypy [configuration file]
(https://mypy.readthedocs.io/en/stable/config_file.html):
[mypy]
plugins = numpy.typing.mypy_plugin
(gh17843)
Let the mypy plugin manage extendedprecision numpy.number
subclasses
The mypy plugin, introduced in
numpy/numpy#17843, has
been expanded: the plugin now removes annotations for platformspecific
extendedprecision types that are not available to the platform in
question. For example, it will remove numpy.float128
when not available.
Without the plugin all extendedprecision types will, as far as mypy
is concerned, be available on all platforms.
To enable the plugin, one must add it to their mypy configuration
file:
[mypy]
plugins = numpy.typing.mypy_plugin
cn
(gh18322)
New min_digits
argument for printing float values
A new min_digits
argument has been added to the dragon4 float printing
functions numpy.format_float_positional
and
numpy.format_float_scientific
. This kwd guarantees
that at least the given number of digits will be printed when printing
in unique=True mode, even if the extra digits are unnecessary to
uniquely specify the value. It is the counterpart to the precision
argument which sets the maximum number of digits to be printed. When
unique=False in fixed precision mode, it has no effect and the precision
argument fixes the number of digits.
(gh18629)
f2py now recognizes Fortran abstract interface blocks
numpy.f2py
can now parse abstract interface blocks.
(gh18695)
BLAS and LAPACK configuration via environment variables
Autodetection of installed BLAS and LAPACK libraries can be bypassed by
using the NPY_BLAS_LIBS
and NPY_LAPACK_LIBS
environment variables.
Instead, the link flags in these environment variables will be used
directly, and the language is assumed to be F77. This is especially
useful in automated builds where the BLAS and LAPACK that are installed
are known exactly. A use case is replacing the actual implementation at
runtime via stub library links.
If NPY_CBLAS_LIBS
is set (optional in addition to NPY_BLAS_LIBS
),
this will be used as well, by defining HAVE_CBLAS
and appending the
environment variable content to the link flags.
(gh18737)
A runtimesubcriptable alias has been added for ndarray
numpy.typing.NDArray
has been added, a runtimesubscriptable alias for
np.ndarray[Any, np.dtype[~Scalar]]
. The new type alias can be used for
annotating arrays with a given dtype and unspecified shape. ^1^
^1^ NumPy does not support the annotating of array shapes as of 1.21,
this is expected to change in the future though (see
646
{.interpretedtext role="pep"}).
Examples
>>> import numpy as np
>>> import numpy.typing as npt
>>> print(npt.NDArray)
numpy.ndarray[typing.Any, numpy.dtype[~ScalarType]]
>>> print(npt.NDArray[np.float64])
numpy.ndarray[typing.Any, numpy.dtype[numpy.float64]]
>>> NDArrayInt = npt.NDArray[np.int_]
>>> a: NDArrayInt = np.arange(10)
>>> def func(a: npt.ArrayLike) > npt.NDArray[Any]:
... return np.array(a)
(gh18935)
Improvements
Arbitrary period
option for numpy.unwrap
The size of the interval over which phases are unwrapped is no longer
restricted to 2 * pi
. This is especially useful for unwrapping
degrees, but can also be used for other intervals.
>>> phase_deg = np.mod(np.linspace(0,720,19), 360)  180
>>> phase_deg
array([180., 140., 100., 60., 20., 20., 60., 100., 140.,
180., 140., 100., 60., 20., 20., 60., 100., 140.,
180.])
>>> unwrap(phase_deg, period=360)
array([180., 140., 100., 60., 20., 20., 60., 100., 140.,
180., 220., 260., 300., 340., 380., 420., 460., 500.,
540.])
(gh16987)
np.unique
now returns single NaN
When np.unique
operated on an array with multiple NaN
entries, its
return included a NaN
for each entry that was NaN
in the original
array. This is now improved such that the returned array contains just
one NaN
as the last element.
Also for complex arrays all NaN
values are considered equivalent (no
matter whether the NaN
is in the real or imaginary part). As the
representant for the returned array the smallest one in the
lexicographical order is chosen  see np.sort
for how the
lexicographical order is defined for complex arrays.
(gh18070)
Generator.rayleigh
and Generator.geometric
performance improved
The performance of Rayleigh and geometric random variate generation in
Generator
has improved. These are both transformation of exponential
random variables and the slow logbased inverse cdf transformation has
been replaced with the Zigguratbased exponential variate generator.
This change breaks the stream of variates generated when variates from
either of these distributions are produced.
(gh18666)
Placeholder annotations have been improved
All placeholder annotations, that were previously annotated as
typing.Any
, have been improved. Where appropiate they have been
replaced with explicit function definitions, classes or other
miscellaneous objects.
(gh18934)
Performance improvements
Improved performance in integer division of NumPy arrays
Integer division of NumPy arrays now uses
libdivide when the divisor is a constant. With
the usage of libdivide and other minor optimizations, there is a large
speedup. The //
operator and np.floor_divide
makes use of the new
changes.
(gh17727)
Improve performance of np.save
and np.load
for small arrays
np.save
is now a lot faster for small arrays.
np.load
is also faster for small arrays, but only when serializing
with a version >= (3, 0)
.
Both are done by removing checks that are only relevant for Python 2,
while still maintaining compatibility with arrays which might have been
created by Python 2.
(gh18657)
Changes
numpy.piecewise
output class now matches the input class
When numpy.ndarray
subclasses are used on input to
numpy.piecewise
, they are passed on to the functions.
The output will now be of the same subclass as well.
(gh18110)
Enable Accelerate Framework
With the release of macOS 11.3, several different issues that numpy was
encountering when using Accelerate Framework's implementation of BLAS
and LAPACK should be resolved. This change enables the Accelerate
Framework as an option on macOS. If additional issues are found, please
file a bug report against Accelerate using the developer feedback
assistant tool (https://developer.apple.com/bugreporting/). We intend
to address issues promptly and plan to continue supporting and updating
our BLAS and LAPACK libraries.
(gh18874)
Checksums
MD5
dbebcfa9ea1ee8e965e5c67dd445f442 numpy1.21.0rc2cp37cp37mmacosx_10_9_x86_64.whl
682e6dc443cdf8bff9941bc8045ee176 numpy1.21.0rc2cp37cp37mmanylinux_2_12_i686.manylinux2010_i686.whl
8c4706bc4dbf63bb8d5befa7be5301ca numpy1.21.0rc2cp37cp37mmanylinux_2_12_x86_64.manylinux2010_x86_64.whl
50702a8708d4b272a9a9c6d4be9c13d7 numpy1.21.0rc2cp37cp37mmanylinux_2_17_aarch64.manylinux2014_aarch64.whl
5ff414f878262c3d4b1f25677c08170e numpy1.21.0rc2cp37cp37mmanylinux_2_5_i686.manylinux1_i686.whl
e39a00070130d7db4a8c21bde7fe343c numpy1.21.0rc2cp37cp37mmanylinux_2_5_x86_64.manylinux1_x86_64.whl
4179696b3d46361c1dca956ede445d71 numpy1.21.0rc2cp37cp37mwin32.whl
a71c9c8713300038fd85f3434c819623 numpy1.21.0rc2cp37cp37mwin_amd64.whl
238168b5be91f15e00bfda8980268c1c numpy1.21.0rc2cp38cp38macosx_10_9_universal2.whl
21cd69e57f6ca956cfb18e5eac7f284b numpy1.21.0rc2cp38cp38macosx_10_9_x86_64.whl
db329a3092104d18265d3186b2024383 numpy1.21.0rc2cp38cp38macosx_11_0_arm64.whl
51d2aea5ba376ab0ba242deefc8d530d numpy1.21.0rc2cp38cp38manylinux_2_12_i686.manylinux2010_i686.whl
72916834e36511fd0381a94e8971c105 numpy1.21.0rc2cp38cp38manylinux_2_12_x86_64.manylinux2010_x86_64.whl
e30845a0aa593380f1385c977b10971f numpy1.21.0rc2cp38cp38manylinux_2_17_aarch64.manylinux2014_aarch64.whl
ae21393c854629fde4c5cea46778f41d numpy1.21.0rc2cp38cp38manylinux_2_5_i686.manylinux1_i686.whl
441b4ac09e2d77f7c96571a728b040a3 numpy1.21.0rc2cp38cp38manylinux_2_5_x86_64.manylinux1_x86_64.whl
f31bd687ec8fd13ecdb0db91763c6ebb numpy1.21.0rc2cp38cp38win32.whl
163c0c4634d5d15b29791fead97571dd numpy1.21.0rc2cp38cp38win_amd64.whl
fd79df4f0255b3b56a93085e5512e778 numpy1.21.0rc2cp39cp39macosx_10_9_universal2.whl
35529757fbbf871dcaecc124e985af67 numpy1.21.0rc2cp39cp39macosx_10_9_x86_64.whl
4138675d78b13511a0b11bc296bd83e6 numpy1.21.0rc2cp39cp39macosx_11_0_arm64.whl
62a72562ff240981bbcfeebc679bc4ee numpy1.21.0rc2cp39cp39manylinux_2_12_i686.manylinux2010_i686.whl
73dd49f6e4d608017b7257c34f4f919e numpy1.21.0rc2cp39cp39manylinux_2_12_x86_64.manylinux2010_x86_64.whl
6aa0da53da74868c5456f9a5a0781616 numpy1.21.0rc2cp39cp39manylinux_2_17_aarch64.manylinux2014_aarch64.whl
8a5342cd72277d89b441bc1125088b87 numpy1.21.0rc2cp39cp39win32.whl
59dbae57afdf57bf2ba9ec402e40366e numpy1.21.0rc2cp39cp39win_amd64.whl
b2ab4d71140295df32992f9a34c61012 numpy1.21.0rc2pp37pypy37_pp73manylinux_2_12_x86_64.manylinux2010_x86_64.whl
44a411dbb345847a89874447cc8fb2c0 numpy1.21.0rc2.tar.gz
ffd8130fbb3046ad090fada62a724aac numpy1.21.0rc2.zip
SHA256
fd11aa1d58b7538076613722a2915d3c3f1c0cd24f674e3194be29729d744dba numpy1.21.0rc2cp37cp37mmacosx_10_9_x86_64.whl
29036b6d56ad35f0637ac84af43f9469b39916ed06aa96729767639e3023ef72 numpy1.21.0rc2cp37cp37mmanylinux_2_12_i686.manylinux2010_i686.whl
5b2752404f6ba22b99617c21dc6c2f15accf61642a5626d239649a96294d8ecb numpy1.21.0rc2cp37cp37mmanylinux_2_12_x86_64.manylinux2010_x86_64.whl
82446d2defd917656c87158a02a7d7e7c03ce8bde9bb39ae5f5b369c5ef561d2 numpy1.21.0rc2cp37cp37mmanylinux_2_17_aarch64.manylinux2014_aarch64.whl
b66b3cdad12d6074ddc46148cefc35c48b0437515c5bf8ce2acd913f486bc257 numpy1.21.0rc2cp37cp37mmanylinux_2_5_i686.manylinux1_i686.whl
74ce56338ff5de5d8b48314a1ec5ebbc2b1c0f9f9d6c00ce1815be0d3f9dcbb4 numpy1.21.0rc2cp37cp37mmanylinux_2_5_x86_64.manylinux1_x86_64.whl
8bb0a19f185e8d4fa60bb036cdc9fb4f34c6486e1d30034f6cacb882efa5252a numpy1.21.0rc2cp37cp37mwin32.whl
a0179c7130aa03f9e60cea9a0b0535b2c2b49f486bae724433cf6ac2abac832f numpy1.21.0rc2cp37cp37mwin_amd64.whl
ce5b195cbcced7c97429ca0323e2e3a19a503fc9ce0e1fea6c5be55e71214ebf numpy1.21.0rc2cp38cp38macosx_10_9_universal2.whl
a59ce04c77711cab0334591650af628151aa515d11bde905198d4e898bb57315 numpy1.21.0rc2cp38cp38macosx_10_9_x86_64.whl
4b8e4c37aea928f0d8359ab24b14382de450180e618972d3b9df50848d084db1 numpy1.21.0rc2cp38cp38macosx_11_0_arm64.whl
09932f5bf0abda5654eda225fd070915942f2c32d9bb6747bd45b66af7a0a9b1 numpy1.21.0rc2cp38cp38manylinux_2_12_i686.manylinux2010_i686.whl
cfb7b67500e6af81a793287ca41912590327051b58da9dc2c0ecb65d35db6ec9 numpy1.21.0rc2cp38cp38manylinux_2_12_x86_64.manylinux2010_x86_64.whl
fec6300b8237aa1c561a8a5fec81ba1bcdf00b622f660897369798a8d57163c4 numpy1.21.0rc2cp38cp38manylinux_2_17_aarch64.manylinux2014_aarch64.whl
a18d4368018f029ea73df53ef801234d2d354e95c32d7890b1102bd2da9857ba numpy1.21.0rc2cp38cp38manylinux_2_5_i686.manylinux1_i686.whl
afebef861665eaa2e491894f2269d1941fbfbb8e5acf565a785107dcfc07613d numpy1.21.0rc2cp38cp38manylinux_2_5_x86_64.manylinux1_x86_64.whl
7d98ade9199b15aa8f589b2263d6028364aecd7a9caf426e65ffc1ba921624a5 numpy1.21.0rc2cp38cp38win32.whl
3c90b0bb77615bda5e007cfa4c53eb6097ecc82e247726e0eb138fcda769b45d numpy1.21.0rc2cp38cp38win_amd64.whl
435090a12dca2232cdbd58740afd5c9ede830037e1f6af60344e3afd49554fc8 numpy1.21.0rc2cp39cp39macosx_10_9_universal2.whl
bee549287cf2fcbf8f8e11b024e62f1a22af296cb1b015aa346d58a01cbfb603 numpy1.21.0rc2cp39cp39macosx_10_9_x86_64.whl
5d4c1b43c84cfe1923dbaed4ef18261a9f7b420983dc209af117c28f32637973 numpy1.21.0rc2cp39cp39macosx_11_0_arm64.whl
93d0cb1b07511d1b108346975cd34cc1c32b7061fbb574ef4ce8fc8139cce417 numpy1.21.0rc2cp39cp39manylinux_2_12_i686.manylinux2010_i686.whl
53e7147d04c75dcf05c3bb38357329d64d4908f403560a1fcb64f7972599c638 numpy1.21.0rc2cp39cp39manylinux_2_12_x86_64.manylinux2010_x86_64.whl
32f683dd175c364b8904bf26ce030a4ff7134aeff0046e3511cbaf855f65583c numpy1.21.0rc2cp39cp39manylinux_2_17_aarch64.manylinux2014_aarch64.whl
f7a0ed76e49c4ab6c53aa43358aa1d943ea5f61cc71844eca1cad8f00794589e numpy1.21.0rc2cp39cp39win32.whl
e2d6388fe28784301fb8293a14d05a5329a9747fa8e451cc189e5f2ee1f422dd numpy1.21.0rc2cp39cp39win_amd64.whl
5a711fbc9bbdb939d082bb856f9812eb3f98a82584ad73eaa924bed6b0695cab numpy1.21.0rc2pp37pypy37_pp73manylinux_2_12_x86_64.manylinux2010_x86_64.whl
e708211e58a32e11ee3b810aa78751776b3723c60edc8dcbadfdd00dab3dc32b numpy1.21.0rc2.tar.gz
cb725aae7c31327e642b876e3195b7fe147bb8d14d85f749ac13ab87d9ab5fab numpy1.21.0rc2.zip