<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/numpy/ticket/1165" rel="nofollow">http://projects.scipy.org/numpy/ticket/1165</a> on 2009-07-10 by trac user dgoldsmith, assigned to <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/pv/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/pv">@pv</a>.</em></p>
<p dir="auto">Proposal regarding modification of the NumPy Docstring Standard</p>
<p dir="auto">Under the heading "Method docstrings" in the section "Documenting classes"</p>
<p dir="auto">Reword as follows:</p>
<p dir="auto">Do not include "self" in the list of parameters.  Otherwise, follow<br>
the docstring standard for an ordinary function, <em>except</em> when the<br>
method duplicates a function in the package namespace.  In such<br>
cases, simply provide the brief summary and the See Also section, whose content should simply be ..</p>
<p dir="auto">On those rare occasions when a method does some additional, significant processing (e.g., parameter manipulation) before (or after) handing off to a nominally equivalent function, then document only the added functionality in the method, using only the sections needed to do so, and for the rest refer to the function.  In general, the guiding principle is to document behavior where it is implemented in the source code, with ufuncs considered to "live" in their function implementation rather than any method implementation they may have.</p>
<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/numpy/ticket/2139" rel="nofollow">http://projects.scipy.org/numpy/ticket/2139</a> on 2012-05-22 by trac user bmu, assigned to unknown.</em></p>
<p dir="auto">I came across a question on stackoverflow (<a href="http://stackoverflow.com/q/9470604" rel="nofollow">http://stackoverflow.com/q/9470604</a>) and I am wondering if this is a bug</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="import numpy as np
dt = np.dtype([('tuple', (int, 2))])
a = np.zeros(3, dt)
type(a['tuple'][0])  # ndarray
type(a[0]['tuple'])  # ndarray

a['tuple'][0] = (1,2)  # ok
a[0]['tuple'] = (1,2)  # ValueError: shape-mismatch on array construction"><pre class="notranslate"><code class="notranslate">import numpy as np
dt = np.dtype([('tuple', (int, 2))])
a = np.zeros(3, dt)
type(a['tuple'][0])  # ndarray
type(a[0]['tuple'])  # ndarray

a['tuple'][0] = (1,2)  # ok
a[0]['tuple'] = (1,2)  # ValueError: shape-mismatch on array construction
</code></pre></div>
<p dir="auto">Travis wrote that this something like a "design" bug in a post at numpy-discussion:</p>
<p dir="auto"><a href="http://permalink.gmane.org/gmane.comp.python.numeric.general/50058" rel="nofollow">http://permalink.gmane.org/gmane.comp.python.numeric.general/50058</a></p>