diff options
author | Ralf Gommers <ralf.gommers@gmail.com> | 2020-05-30 14:48:58 +0200 |
---|---|---|
committer | Ralf Gommers <ralf.gommers@gmail.com> | 2020-06-01 11:55:33 +0200 |
commit | 5e19fe8e19f0b30a369dcc3323a5c32ce064c572 (patch) | |
tree | f800e808c148bff0ab31e58880c18a47ccdd49da /doc/neps | |
parent | bdd4e2e29c4b011cf455a72f85c92010656d2722 (diff) | |
download | numpy-5e19fe8e19f0b30a369dcc3323a5c32ce064c572.tar.gz |
DOC: update roadmap
Removes completed items and other outdated content, plus some things
that are too detailed or not high-prio enough to be on the roadmap.
Add new items that are being actively worked on or for which there's a
lot of interest. Link the most relevant NEPs.
Diffstat (limited to 'doc/neps')
-rw-r--r-- | doc/neps/roadmap.rst | 87 |
1 files changed, 48 insertions, 39 deletions
diff --git a/doc/neps/roadmap.rst b/doc/neps/roadmap.rst index 3780499a0..de4462cb9 100644 --- a/doc/neps/roadmap.rst +++ b/doc/neps/roadmap.rst @@ -6,6 +6,7 @@ This is a live snapshot of tasks and features we will be investing resources in. It may be used to encourage and inspire developers and to search for funding. + Interoperability ---------------- @@ -16,11 +17,21 @@ facilitate interoperability with all such packages, and the code that uses them, may include (among other things) interoperability protocols, better duck typing support and ndarray subclass handling. -- The ``__array_function__`` protocol is currently experimental and needs to be - matured. See :ref`NEP18` for details. -- New protocols for overriding other functionality in NumPy may be needed. -- Array duck typing, or handling "duck arrays", needs improvements. See - :ref:`NEP22` for details. +The ``__array_ufunc__`` and ``__array_function__`` protocols are stable, but +do not cover the whole API. New protocols for overriding other functionality +in NumPy are needed. Work in this area aims to bring to completion one or more +of the following proposals: + +- :ref:`NEP30` +- :ref:`NEP31` +- :ref:`NEP35` +- :ref:`NEP37` + +In addition we aim to provide ways to make it easier for other libraries to +implement a NumPy-compatible API. This may include defining consistent subsets +of the API, as discussed in `this section of NEP 37 +<https://numpy.org/neps/nep-0037-array-module.html#requesting-restricted-subsets-of-numpy-s-api>`__. + Extensibility ------------- @@ -42,15 +53,13 @@ improve the dtype system. - One of these should probably be the default for text data. The current behavior on Python 3 is neither efficient nor user friendly. -- ``np.dtype(int)`` should not be platform dependent -- Better coercion for string + number Performance ----------- We want to further improve NumPy's performance, through: -- Better use of SIMD instructions, also on platforms other than x86. +- Better use of SIMD instructions, also on platforms other than x86 - see :ref:`NEP38`. - Reducing ufunc overhead. - Optimizations in individual functions. @@ -58,40 +67,40 @@ Furthermore we would like to improve the benchmarking system, in terms of covera easy of use, and publication of the results (now `here <https://pv.github.io/numpy-bench>`__) as part of the docs or website. + Website and documentation ------------------------- -Our website (https://numpy.org) is in very poor shape and needs to be rewritten -completely. - -The NumPy `documentation <https://www.numpy.org/devdocs/user/index.html>`__ is -of varying quality - in particular the User Guide needs major improvements. +Our website (https://numpy.org) was completely redesigned recently. We aim to +further improve it by adding translations, better Hugo-Sphinx integration via a +new Sphinx theme, and more (see `this tracking issue <https://github.com/numpy/numpy.org/issues/266>`__). -Random number generation policy & rewrite ------------------------------------------ +The NumPy `documentation <https://www.numpy.org/devdocs>`__ is of varying +quality. The API documentation is in good shape, high-level documentation on +many topics is missing or outdated. See :ref:`NEP44` for planned improvements. -A new random number generation framework with higher performance generators is -close to completion, see :ref:`NEP19` and `PR 13163`_. -Indexing --------- +User experience +--------------- -We intend to add new indexing modes for "vectorized indexing" and "outer indexing", -see :ref:`NEP21`. +Type annotations +```````````````` +We aim to add type annotations for all NumPy functionality, so users can use +tools like `mypy`_ to type check their code and IDEs can improve their support +for NumPy. The existing type stubs in the `numpy-stubs`_ repository are being +improved and will be moved into the NumPy code base. -Continuous Integration ----------------------- +Platform support +```````````````` +We aim to increase our support for different hardware architectures. This +includes adding CI coverage when CI services are available, providing wheels on +PyPI for ARM64 (``aarch64``) and POWER8/9 (``ppc64le``), providing better +build and install documentation, and resolving build issues on other platforms +like AIX. -We depend on CI to discover problems as we continue to develop NumPy before the -code reaches downstream users. -- CI for more exotic platforms (if available as a service). -- Multi-package testing -- Add an official channel for numpy dev builds for CI usage by other projects so - they may confirm new builds do not break their package. - -Other functionality -------------------- +Maintenance +----------- - ``MaskedArray`` needs to be improved, ideas include: @@ -99,12 +108,12 @@ Other functionality - MaskedArray as a duck-array type, and/or - dtypes that support missing values -- A backend system for ``numpy.fft`` (so that e.g. ``fft-mkl`` doesn't need to monkeypatch numpy) -- Write a strategy on how to deal with overlap between NumPy and SciPy for ``linalg`` - and ``fft`` (and implement it). -- Deprecate ``np.matrix`` (very slowly) +- Fortran integration via ``numpy.f2py`` requires a number of improvements, see + `this tracking issue <https://github.com/numpy/numpy/issues/14938>`__. +- A backend system for ``numpy.fft`` (so that e.g. ``fft-mkl`` doesn't need to monkeypatch numpy). +- Write a strategy on how to deal with overlap between NumPy and SciPy for ``linalg``. +- Deprecate ``np.matrix`` (very slowly). -.. _implementation: https://gist.github.com/shoyer/1f0a308a06cd96df20879a1ddb8f0006 -.. _`reference implementation`: https://github.com/bashtage/randomgen -.. _`PR 13163`: https://github.com/numpy/numpy/pull/13163 +.. _`mypy`: https://mypy.readthedocs.io +.. _`numpy-stubs`: https://github.com/numpy/numpy-stubs |