change all non-code instances of Numpy to NumPy

Instances remain for NumpyVersion and Numpy.rec.fromarrays that are
references to code.

Release notes were left unchanged.

see issue numpy#7986

doc/C_STYLE_GUIDE.rst.txt

@@ -6,7 +6,7 @@ The NumPy C coding conventions are based on Python PEP-0007 by Guido van
 Rossum with a few added strictures. There are many C coding conventions and
 it must be emphasized that the primary goal of the NumPy conventions isn't
 to choose the 'best', about which there is certain to be disagreement, but
-to achieve uniformity. Because the Numpy conventions are very close to
+to achieve uniformity. Because the NumPy conventions are very close to
 those in PEP-0007, that PEP is used as a template below with the NumPy
 additions and variations in the appropriate spots.
 
@@ -17,7 +17,7 @@ Introduction
 ------------
 
 This document gives coding conventions for the C code comprising
-the C implementation of Numpy. Note, rules are there to be broken.
+the C implementation of NumPy. Note, rules are there to be broken.
 Two good reasons to break a particular rule:
 
 1. When applying the rule would make the code less readable, even
@@ -53,7 +53,7 @@ C dialect
   Note: this will change with the proposed transition to C++.
 
 * No compiler warnings with major compilers (gcc, VC++, a few others).
-  Note: Numpy still produces compiler warnings that need to be addressed.
+  Note: NumPy still produces compiler warnings that need to be addressed.
 
 
 Code lay-out
@@ -195,7 +195,7 @@ Code lay-out
 Naming conventions
 ------------------
 
-* There has been no consistent prefix for Numpy public functions, but
+* There has been no consistent prefix for NumPy public functions, but
   they all begin with a prefix of some sort, followed by an underscore, and
   are in camel case: ``PyArray_DescrAlignConverter``, ``NpyIter_GetIterNext``.
   In the future the names should be of the form ``Npy*_PublicFunction``,
@@ -213,7 +213,7 @@ Naming conventions
 Function documentation
 ----------------------
 
-Numpy doesn't have a C function documentation standard at this time, but
+NumPy doesn't have a C function documentation standard at this time, but
 needs one. Most numpy functions are not documented in the code and that
 should change. One possibility is Doxygen with a plugin so that the same
 NumPy style used for Python functions can also be used for documenting

doc/HOWTO_BUILD_DOCS.rst.txt

@@ -3,7 +3,7 @@ Building the NumPy API and reference docs
 =========================================
 
 We currently use Sphinx_ for generating the API and reference
-documentation for Numpy.  You will need Sphinx 1.0.1 or newer.
+documentation for NumPy.  You will need Sphinx 1.0.1 or newer.
 
 If you only want to get the documentation, note that pre-built
 versions can be found at
@@ -18,7 +18,7 @@ in several different formats.
 Instructions
 ------------
 
-If you obtained Numpy via git, get also the git submodules that contain
+If you obtained NumPy via git, get also the git submodules that contain
 additional parts required for building the documentation::
 
     git submodule init
@@ -30,15 +30,15 @@ be installed with or without completely installing Matplotlib: see the
 Matplotlib documentation for more information.
 
 Since large parts of the main documentation are stored in
-docstrings, you will need to first build Numpy, and install it so
+docstrings, you will need to first build NumPy, and install it so
 that the correct version is imported by
 
     >>> import numpy
 
-Note that you can eg. install Numpy to a temporary location and set
+Note that you can eg. install NumPy to a temporary location and set
 the PYTHONPATH environment variable appropriately.
 
-After Numpy is installed, write::
+After NumPy is installed, write::
 
     make html
 
@@ -59,11 +59,11 @@ Instead of the above, you can also do::
 
    make dist
 
-which will rebuild Numpy, install it to a temporary location, and
+which will rebuild NumPy, install it to a temporary location, and
 build the documentation in all formats. This will most likely again
 only work on Unix platforms.
 
-The documentation for Numpy distributed at http://docs.scipy.org in html and
+The documentation for NumPy distributed at http://docs.scipy.org in html and
 pdf format is also built with ``make dist``.  See `HOWTO RELEASE`_ for details on
 how to update http://docs.scipy.org.
 
@@ -73,9 +73,9 @@ how to update http://docs.scipy.org.
 Sphinx extensions
 -----------------
 
-Numpy's documentation uses several custom extensions to Sphinx.  These
+NumPy's documentation uses several custom extensions to Sphinx.  These
 are shipped in the ``sphinxext/`` directory (as git submodules, as discussed
-above), and are automatically enabled when building Numpy's documentation.
+above), and are automatically enabled when building NumPy's documentation.
 
 If you want to make use of these extensions in third-party
 projects, they are available on PyPi_ as the numpydoc_ package.

doc/HOWTO_DOCUMENT.rst.txt

@@ -141,7 +141,7 @@ The sections of the docstring are:
    A section (use if applicable) to warn users that the object is deprecated.
    Section contents should include:
 
-   * In what Numpy version the object was deprecated, and when it will be
+   * In what NumPy version the object was deprecated, and when it will be
      removed.
 
    * Reason for deprecation if this is useful information (e.g., object
@@ -154,8 +154,8 @@ The sections of the docstring are:
 
    ::
 
-     .. note:: Deprecated in Numpy 1.6
-               `ndobj_old` will be removed in Numpy 2.0, it is replaced by
+     .. note:: Deprecated in NumPy 1.6
+               `ndobj_old` will be removed in NumPy 2.0, it is replaced by
                `ndobj_new` because the latter works also with array subclasses.
 
 3. **Extended Summary**
@@ -529,7 +529,7 @@ as appropriate.
 
 Documenting class instances
 ---------------------------
-Instances of classes that are part of the Numpy API (for example `np.r_`
+Instances of classes that are part of the NumPy API (for example `np.r_`
 `np,c_`, `np.index_exp`, etc.) may require some care. To give these
 instances a useful docstring, we do the following:
 

doc/HOWTO_RELEASE.rst.txt

@@ -302,7 +302,7 @@ to public keyservers, with a command such as::
 
 Apply patch to fix bogus strides
 --------------------------------
-NPY_RELAXED_STRIDE_CHECKING was made the default in Numpy 1.10 and bogus
+NPY_RELAXED_STRIDE_CHECKING was made the default in NumPy 1.10 and bogus
 strides are used in the development branch to smoke out problems. The
 `patch <https://github.com/numpy/numpy/pull/5996>`_ should be updated if
 necessary and applied to the release branch to rationalize the strides.

doc/Py3K.rst.txt

@@ -11,7 +11,7 @@ Developer notes on the transition to Python 3
 General
 =======
 
-Numpy has now been ported to Python 3.
+NumPy has now been ported to Python 3.
 
 Some glitches may still be present; however, we are not aware of any
 significant ones, the test suite passes.
@@ -125,7 +125,7 @@ F2py is ported to Py3.
 Bytes vs. strings
 -----------------
 
-At many points in Numpy, bytes literals are needed. These can be created via
+At many points in NumPy, bytes literals are needed. These can be created via
 numpy.compat.asbytes and asbytes_nested.
 
 
@@ -245,7 +245,7 @@ Any new ones that need to be added should be added in this file.
 
 .. todo::
 
-   Remove PyString_* eventually -- having a call to one of these in Numpy
+   Remove PyString_* eventually -- having a call to one of these in NumPy
    sources is a sign of an error...
 
 
@@ -527,7 +527,7 @@ There are two issues related to the str/bytes change:
 This entry discusses return values etc. only, the 'S' dtype is a
 separate topic.
 
-All uses of PyString in Numpy should be changed to one of
+All uses of PyString in NumPy should be changed to one of
 
 - PyBytes: one-byte character strings in Py2 and Py3
 - PyUString (defined in npy_3kconfig.h): PyString in Py2, PyUnicode in Py3
@@ -554,7 +554,7 @@ Some specific decisions that have been made so far:
 
 * descriptor.c: dtype field names are UString
 
-  At some places in Numpy code, there are some guards for Unicode field
+  At some places in NumPy code, there are some guards for Unicode field
   names. However, the dtype constructor accepts only strings as field names,
   so we should assume field names are *always* UString.
 
@@ -604,7 +604,7 @@ PyUnicode
 PyUnicode in Py3 is pretty much as it was in Py2, except that it is
 now the only "real" string type.
 
-In Py3, Unicode and Bytes are not comparable, ie., 'a' != b'a'.  Numpy
+In Py3, Unicode and Bytes are not comparable, ie., 'a' != b'a'.  NumPy
 comparison routines were handled to act in the same way, leaving
 comparison between Unicode and Bytes undefined.
 
@@ -627,25 +627,25 @@ PyInt
 -----
 
 There is no limited-range integer type any more in Py3.  It makes no
-sense to inherit Numpy ints from Py3 ints.
+sense to inherit NumPy ints from Py3 ints.
 
 Currently, the following is done:
 
-1) Numpy's integer types no longer inherit from Python integer.
+1) NumPy's integer types no longer inherit from Python integer.
 2) int is taken dtype-equivalent to NPY_LONG
 3) ints are converted to NPY_LONG
 
 PyInt methods are currently replaced by PyLong, via macros in npy_3kcompat.h.
 
-Dtype decision rules were changed accordingly, so that Numpy understands
+Dtype decision rules were changed accordingly, so that NumPy understands
 Py3 int translate to NPY_LONG as far as dtypes are concerned.
 
 array([1]).dtype will be the default NPY_LONG integer.
 
 .. todo::
 
    Not inheriting from `int` on Python 3 makes the following not work:
-   ``np.intp("0xff", 16)`` -- because the Numpy type does not take
+   ``np.intp("0xff", 16)`` -- because the NumPy type does not take
    the second argument. This could perhaps be fixed...
 
 
@@ -707,7 +707,7 @@ Module initialization
 
 The module initialization API changed in Python 3.1.
 
-Most Numpy modules are now converted.
+Most NumPy modules are now converted.
 
 
 PyTypeObject
@@ -871,7 +871,7 @@ obtained must be closed with fclose after use.
 
    Should probably be done much later on...
 
-   Adapt all Numpy I/O to use the PyFile_* methods or the low-level
+   Adapt all NumPy I/O to use the PyFile_* methods or the low-level
    IO routines. In any case, it's unlikely that C stdio can be used any more.
 
    Perhaps using PyFile_* makes numpy.tofile e.g. to a gzip to work?
@@ -914,4 +914,4 @@ PyCObject / PyCapsule
 The PyCObject API is removed in Python 3.2, so we need to rewrite it
 using PyCapsule.
 
-Numpy was changed to use the Capsule API, using NpyCapsule* wrappers.
+NumPy was changed to use the Capsule API, using NpyCapsule* wrappers.

doc/TESTS.rst.txt

@@ -382,5 +382,5 @@ Tests on random data are good, but since test failures are meant to expose
 new bugs or regressions, a test that passes most of the time but fails
 occasionally with no code changes is not helpful. Make the random data
 deterministic by setting the random number seed before generating it.  Use
-either Python's ``random.seed(some_number)`` or Numpy's
+either Python's ``random.seed(some_number)`` or NumPy's
 ``numpy.random.seed(some_number)``, depending on the source of random numbers.

doc/cdoc/README

@@ -1,7 +1,7 @@
 cdoc
 ====
 
-This is a simple Doxygen project for building Numpy C code documentation,
+This is a simple Doxygen project for building NumPy C code documentation,
 with docstrings extracted from the C sources themselves.
 
 The understood syntax for documentation in the C source is

doc/neps/missing-data.rst

@@ -884,7 +884,7 @@ a few different access patterns people use to get ahold of the numpy array data,
 here we examine a few of them to see what numpy can do. These examples are
 found from doing google searches of numpy C API array access.
 
-Numpy Documentation - How to extend NumPy
+NumPy Documentation - How to extend NumPy
 -----------------------------------------
 
 http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#dealing-with-array-objects

doc/neps/new-iterator-ufunc.rst

@@ -51,7 +51,7 @@ NumPy defaults to returning C-contiguous arrays from UFuncs.  This can
 result in extremely poor memory access patterns when dealing with data
 that is structured differently.  A simple timing example illustrates
 this with a more than eight times performance hit from adding
-Fortran-contiguous arrays together.  All timings are done using Numpy
+Fortran-contiguous arrays together.  All timings are done using NumPy
 2.0dev (Nov 22, 2010) on an Athlon 64 X2 4200+, with a 64-bit OS.::
 
     In [1]: import numpy as np

doc/neps/ufunc-overrides.rst

@@ -176,7 +176,7 @@ The ``__numpy_ufunc__`` mechanism is fully independent of Python's
 standard operator override mechanism, and the two do not interact
 directly.
 
-They however have indirect interactions, because Numpy's ``ndarray``
+They however have indirect interactions, because NumPy's ``ndarray``
 type implements its binary operations via Ufuncs. Effectively, we have::
 
     class ndarray(object):
@@ -208,14 +208,14 @@ undesirable behavior.
 
 The reason why this occurs is: because ``MyObject`` is not an ndarray
 subclass, Python resolves the expression ``b * a`` by calling first
-``b.__mul__``. Since Numpy implements this via an Ufunc, the call is
+``b.__mul__``. Since NumPy implements this via an Ufunc, the call is
 forwarded to ``__numpy_ufunc__`` and not to ``__rmul__``.  Note that if
 ``MyObject`` is a subclass of ``ndarray``, Python calls ``a.__rmul__``
 first. The issue is therefore that ``__numpy_ufunc__`` implements
 "virtual subclassing" of ndarray behavior, without actual subclassing.
 
 This issue can be resolved by a modification of the binary operation
-methods in Numpy::
+methods in NumPy::
 
     class ndarray(object):
         ...

doc/source/_templates/indexcontent.html

@@ -3,13 +3,13 @@
   <p><strong>Parts of the documentation:</strong></p>
   <table class="contentstable" align="center"><tr>
     <td width="50%">
-      <p class="biglink"><a class="biglink" href="{{ pathto("user/index") }}">Numpy User Guide</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("user/index") }}">NumPy User Guide</a><br/>
          <span class="linkdescr">start here</span></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("reference/index") }}">Numpy Reference</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("reference/index") }}">NumPy Reference</a><br/>
          <span class="linkdescr">reference documentation</span></p>
       <p class="biglink"><a class="biglink" href="{{ pathto("f2py/index") }}">F2Py Guide</a><br/>
          <span class="linkdescr">f2py documentation</span></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("dev/index") }}">Numpy Developer Guide</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("dev/index") }}">NumPy Developer Guide</a><br/>
          <span class="linkdescr">contributing to NumPy</span></p>
     </td></tr>
   </table>
@@ -34,28 +34,28 @@
     <td width="50%">
       <p class="biglink"><a class="biglink" href="{{ pathto("bugs") }}">Reporting bugs</a></p>
       <p class="biglink"><a class="biglink" href="{{ pathto("about") }}">About NumPy</a></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("neps/index") }}">Numpy Enhancement Proposals</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("neps/index") }}">NumPy Enhancement Proposals</a><br/>
     </td><td width="50%">
       <p class="biglink"><a class="biglink" href="{{ pathto("release") }}">Release Notes</a></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("license") }}">License of Numpy</a></p>
+      <p class="biglink"><a class="biglink" href="{{ pathto("license") }}">License of NumPy</a></p>
     </td></tr>
   </table>
 
   <h2>Acknowledgements</h2>
   <p>
     Large parts of this manual originate from Travis E. Oliphant's book
-    <a href="http://www.tramy.us/">"Guide to Numpy"</a> (which generously entered
+    <a href="http://www.tramy.us/">"Guide to NumPy"</a> (which generously entered
     Public Domain in August 2008). The reference documentation for many of
     the functions are written by numerous contributors and developers of
-    Numpy, both prior to and during the
-    <a href="http://docs.scipy.org/numpy/">Numpy Documentation Marathon</a>.
+    NumPy, both prior to and during the
+    <a href="http://docs.scipy.org/numpy/">NumPy Documentation Marathon</a>.
   </p>
   <p>
     The preferred way to update the documentation is by submitting a pull
     request on Github (see the 
     <a href="http://docs.scipy.org/doc/numpy-dev/dev/">Developer Guide</a>.
-    The <a href="http://docs.scipy.org/numpy/">Numpy Documentation Wiki</a>
+    The <a href="http://docs.scipy.org/numpy/">NumPy Documentation Wiki</a>
     can also still be used to submit documentation fixes.
-    Please help us to further improve the Numpy documentation!
+    Please help us to further improve the NumPy documentation!
   </p>
 {% endblock %}

doc/source/about.rst

@@ -25,7 +25,7 @@ by *Numarray* and can also be used to replace *Numarray*.
 NumPy community
 ---------------
 
-Numpy is a distributed, volunteer, open-source project. *You* can help
+NumPy is a distributed, volunteer, open-source project. *You* can help
 us make it better; if you believe something should be improved either
 in functionality or in documentation, don't hesitate to contact us --- or
 even better, contact us and participate in fixing the problem.
@@ -36,11 +36,11 @@ Our main means of communication are:
 
 - `Mailing lists <http://scipy.org/Mailing_Lists>`__
 
-- `Numpy Issues <https://github.com/numpy/numpy/issues>`__ (bug reports go here)
+- `NumPy Issues <https://github.com/numpy/numpy/issues>`__ (bug reports go here)
 
-- `Old Numpy Trac <http://projects.scipy.org/numpy>`__ (no longer used)
+- `Old NumPy Trac <http://projects.scipy.org/numpy>`__ (no longer used)
 
-More information about the development of Numpy can be found at
+More information about the development of NumPy can be found at
 http://scipy.org/Developer_Zone
 
 If you want to fix issues in this documentation, the easiest way

doc/source/bugs.rst

@@ -5,7 +5,7 @@ Reporting bugs
 File bug reports or feature requests, and make contributions
 (e.g. code patches), by opening a "new issue" on GitHub:
 
-- Numpy Issues: http://github.com/numpy/numpy/issues
+- NumPy Issues: http://github.com/numpy/numpy/issues
 
 Please give as much information as you can in the ticket. It is extremely
 useful if you can supply a small self-contained code snippet that reproduces