summaryrefslogtreecommitdiff
path: root/doc/neps
diff options
context:
space:
mode:
authorRalf Gommers <ralf.gommers@gmail.com>2020-05-30 14:48:58 +0200
committerRalf Gommers <ralf.gommers@gmail.com>2020-06-01 11:55:33 +0200
commit5e19fe8e19f0b30a369dcc3323a5c32ce064c572 (patch)
treef800e808c148bff0ab31e58880c18a47ccdd49da /doc/neps
parentbdd4e2e29c4b011cf455a72f85c92010656d2722 (diff)
downloadnumpy-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.rst87
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