summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2020-04-28 13:16:18 -0500
committerSebastian Berg <sebastian@sipsolutions.net>2020-04-28 13:17:44 -0500
commit5f65c90f04761e82f0d983ad615fbf9decb33593 (patch)
treea95d1281a1738b7cdadfe0d203c4e55a9fa69fb8
parent7e3fd81c039b0e22715c4e6eb63439bdf5a620bf (diff)
downloadnumpy-5f65c90f04761e82f0d983ad615fbf9decb33593.tar.gz
NEP 41: Accept NEP 41 and add DType<->scalar duplication paragraph
Also adds the resolution email and PR as well as mailing discussion threads.
-rw-r--r--doc/neps/nep-0041-improved-dtype-support.rst23
1 files changed, 20 insertions, 3 deletions
diff --git a/doc/neps/nep-0041-improved-dtype-support.rst b/doc/neps/nep-0041-improved-dtype-support.rst
index 6310741e0..173d7475c 100644
--- a/doc/neps/nep-0041-improved-dtype-support.rst
+++ b/doc/neps/nep-0041-improved-dtype-support.rst
@@ -8,10 +8,10 @@ NEP 41 — First step towards a new Datatype System
:Author: Sebastian Berg
:Author: Stéfan van der Walt
:Author: Matti Picus
-:Status: Draft
+:Status: Accepted
:Type: Standard Track
:Created: 2020-02-03
-
+:Resolution: https://mail.python.org/pipermail/numpy-discussion/2020-April/080573.html and https://mail.python.org/pipermail/numpy-discussion/2020-March/080495.html
.. note::
@@ -601,12 +601,22 @@ Inheritance, however, appears problematic and a complexity best avoided
Further, subclasses may be more interesting for interoperability for
example with GPU backends (CuPy) storing additional methods related to the
GPU rather than as a mechanism to define new datatypes.
-A class hierarchy does provides value, this may be achieved by
+A class hierarchy does provides value, and one can be achieved by
allowing the creation of *abstract* datatypes.
An example for an abstract datatype would be the datatype equivalent of
``np.floating``, representing any floating point number.
These can serve the same purpose as Python's abstract base classes.
+This NEP chooses to duplicate the scalar hierarchy fully or in part.
+The main reason is to uncouple the implementation of the DType and scalar.
+To add a DType to NumPy, in theory the scalar will not need to be
+modified or know about NumPy. Also note that the categorical DType as
+currently implemented in pandas does not have a scalar correspondence
+making it less straight forward to rely on scalars to implement behaviour.
+While DType and Scalar describe the same concept/type (e.g. an `int64`),
+it seems practical to split out the information and functionality necessary
+for numpy into the DType class.
+
Scalars should not be instances of the datatypes (2)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -706,6 +716,13 @@ Discussion
See `NEP 40 <NEP40>`_ for a list of previous meetings and discussions.
+Additional discussion around this specific NEP has occured on both
+the mailing list and the pull request:
+
+* `Mailing list discussion <https://mail.python.org/pipermail/numpy-discussion/2020-March/080481.html>`_
+* `NEP 41 pull request <https://github.com/numpy/numpy/pull/15506>`_
+* `Pull request thread on Dtype hierarchy and Scalars <https://github.com/numpy/numpy/pull/15506#discussion_r390016298>`_
+
References
----------