diff options
| -rw-r--r-- | doc/neps/roadmap.rst | 81 |
1 files changed, 44 insertions, 37 deletions
diff --git a/doc/neps/roadmap.rst b/doc/neps/roadmap.rst index 40fcbd325..7e5d1a03b 100644 --- a/doc/neps/roadmap.rst +++ b/doc/neps/roadmap.rst @@ -17,6 +17,12 @@ 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 key goal is: *make it easy for code written for NumPy to also work with +other NumPy-like projects.* This will enable GPU support via, e.g, CuPy or JAX, +distributed array support via Dask, and writing special-purpose arrays (either +from scratch, or as a ``numpy.ndarray`` subclass) that work well with SciPy, +scikit-learn and other such packages. + 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 @@ -33,56 +39,59 @@ 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 -------------- - -We aim to make it much easier to extend NumPy. The primary topic here is to -improve the dtype system. - -- Easier custom dtypes: - - - Simplify and/or wrap the current C-API - - More consistent support for dtype metadata - - Support for writing a dtype in Python - -- New string dtype(s): - - - Encoded strings with fixed-width storage (utf8, latin1, ...) and/or - - Variable length strings (could share implementation with dtype=object, - but are explicitly type-checked) - - One of these should probably be the default for text data. The current - behavior on Python 3 is neither efficient nor user friendly. - - Performance ----------- -Improvements to NumPy's performance are important to many users. The primary -topic at the moment is better use of SIMD instructions, also on platforms other -than x86 - see :ref:`NEP38`. +Improvements to NumPy's performance are important to many users. We have +focused this effort on Universal SIMD (see :ref:`NEP38`) intrinsics which +provide nice improvements across various hardware platforms via an abstraction +layer. The infrastructure is in place, and we welcome follow-on PRs to add +SIMD support across all relevant NumPy functions. Other performance improvement ideas include: -- Reducing ufunc and ``__array_function__`` overhead. -- Optimizations in individual functions. - A better story around parallel execution. +- Optimizations in individual functions. +- Reducing ufunc and ``__array_function__`` overhead. Furthermore we would like to improve the benchmarking system, in terms of coverage, 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 +Documentation and website ------------------------- The NumPy `documentation <https://www.numpy.org/devdocs>`__ is of varying quality. The API documentation is in good shape; tutorials and high-level documentation on many topics are missing or outdated. See :ref:`NEP44` for -planned improvements. +planned improvements. Adding more tutorials is underway in the +`numpy-tutorials repo <https://github.com/numpy/numpy-tutorials>`__. 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>`__). +further improve it by adding translations, more case studies and other +high-level content, and more (see `this tracking issue <https://github.com/numpy/numpy.org/issues/266>`__). + + +Extensibility +------------- + +We aim to make it much easier to extend NumPy. The primary topic here is to +improve the dtype system - see :ref:`NEP41` and related NEPs linked from it. +Concrete goals for the dtype system rewrite are: + +- Easier custom dtypes: + + - Simplify and/or wrap the current C-API + - More consistent support for dtype metadata + - Support for writing a dtype in Python + +- Allow adding (a) new string dtype(s). This could be encoded strings with + fixed-width storage (e.g., ``utf8`` or ``latin1``), and/or a variable length + string dtype. The latter could share an implementation with ``dtype=object``, + but be explicitly type-checked. + One of these should probably be the default for text data. The current + string dtype support is neither efficient nor user friendly. User experience @@ -90,18 +99,17 @@ User experience Type annotations ```````````````` -We aim to add type annotations for all NumPy functionality, so users can use +NumPy 1.20 adds type annotations for most 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. +for NumPy. Improving those type annotations, for example to support annotating +array shapes and dtypes, is ongoing. 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. +PyPI for POWER8/9 (``ppc64le``), providing better build and install +documentation, and resolving build issues on other platforms like AIX. Maintenance @@ -126,4 +134,3 @@ Maintenance .. _`mypy`: https://mypy.readthedocs.io -.. _`numpy-stubs`: https://github.com/numpy/numpy-stubs |