diff options
| author | Hameer Abbasi <hameerabbasi@yahoo.com> | 2019-07-31 20:35:18 +0500 |
|---|---|---|
| committer | Hameer Abbasi <hameerabbasi@yahoo.com> | 2019-07-31 20:35:18 +0500 |
| commit | 014c5ef4c3b0eae2558391d94466ec648992132f (patch) | |
| tree | 9163f95ddcdb1caf12c21532b46af43ec59a91aa | |
| parent | 3691300fac685afe3677449c78c7334011d18406 (diff) | |
| download | numpy-014c5ef4c3b0eae2558391d94466ec648992132f.tar.gz | |
Complete incomplete sentence.
| -rw-r--r-- | doc/neps/nep-0030-uarray.rst | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/doc/neps/nep-0030-uarray.rst b/doc/neps/nep-0030-uarray.rst index b3883492a..f32c6e781 100644 --- a/doc/neps/nep-0030-uarray.rst +++ b/doc/neps/nep-0030-uarray.rst @@ -32,9 +32,11 @@ This NEP takes a more holistic approach: It assumes that there are parts of the overridable, and that these will grow over time. It provides a general framework and a mechanism to avoid a design of a new protocol each time this is required. -The second is to ease the creation of new duck-arrays, +The second is to ease the creation of new duck-arrays, by providing default implementations of many +functions that can be easily expressed in terms of others, as well as a repository of utility functions +that help in the implementation of duck-arrays that most duck-arrays would require. -The second is the existence of actual, third party dtype packages, and +The third is the existence of actual, third party dtype packages, and their desire to blend into the NumPy ecosystem. `[6]`_. This is a separate issue compared to the C-level dtype redesign proposed in `[7]`_, it's about allowing third-party dtype implementations to work with NumPy, much like third-party array |