diff options
| author | Matti Picus <matti.picus@gmail.com> | 2020-04-29 00:08:08 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-04-29 00:08:08 +0300 |
| commit | d13a4f06ea84da112d5069b3fde148e307e7f94c (patch) | |
| tree | cf8a404eee560665374b7ffd5a6b7d149973fef0 | |
| parent | e67737e2e63e36161c8f80715c0a347e46a06d91 (diff) | |
| parent | 5f65c90f04761e82f0d983ad615fbf9decb33593 (diff) | |
| download | numpy-d13a4f06ea84da112d5069b3fde148e307e7f94c.tar.gz | |
Merge pull request #16100 from seberg/accept-nep41
NEP 41: Accept NEP 41 and add DType<->scalar duplication paragraph
| -rw-r--r-- | doc/neps/nep-0041-improved-dtype-support.rst | 23 |
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 ---------- |