summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorAnirudh Subramanian <anirudh2290@ufl.edu>2020-04-21 02:25:03 +0000
committerAnirudh Subramanian <anirudh2290@ufl.edu>2020-04-24 23:29:34 +0000
commit31910e196e13d1042cae3e6c334c38318cf8dfaa (patch)
tree9154dc0ec633d6e1acf1d690cbbdee14f81d3c4a /doc
parent9eb7560e77c43af561f5242cf30df6b1d7442e83 (diff)
downloadnumpy-31910e196e13d1042cae3e6c334c38318cf8dfaa.tar.gz
NEP, DOC: Small typo fixes to the doc
Diffstat (limited to 'doc')
-rw-r--r--doc/neps/nep-0040-legacy-datatype-impl.rst6
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/neps/nep-0040-legacy-datatype-impl.rst b/doc/neps/nep-0040-legacy-datatype-impl.rst
index 799c6c026..c9a4fd7c8 100644
--- a/doc/neps/nep-0040-legacy-datatype-impl.rst
+++ b/doc/neps/nep-0040-legacy-datatype-impl.rst
@@ -180,8 +180,8 @@ These issues do not need to solved right away:
scalars behave much like NumPy arrays, a feature that general Python objects
do not have.
* Seamless integration probably requires that ``np.array(scalar)`` finds the
- correct DType automatically since some operations (such as indexing) are
- return the scalar instead of a 0D array.
+ correct DType automatically since some operations (such as indexing) return
+ the scalar instead of a 0D array.
This is problematic if multiple users independently decide to implement
for example a DType for ``decimal.Decimal``.
@@ -207,7 +207,7 @@ Many datatype-specific functions are defined within a C structure called
:c:type:`PyArray_ArrFuncs`, which is part of each ``dtype`` instance and
has a similarity to Python's ``PyNumberMethods``.
For user-defined datatypes this structure is exposed to the user, making
-ABI-compatible changes changes impossible.
+ABI-compatible changes impossible.
This structure holds important information such as how to copy or cast,
and provides space for pointers to functions, such as comparing elements,
converting to bool, or sorting.