homepage

With attached patch python -mpydoc memoryview display looks as follows:
...
 | cast(...)
 | M.cast(format[, shape]) -> memoryview
 | 
 | Cast a memoryview to a new format or shape.
 | 
 | release(...)
 | M.release() -> None
 | 
 | Release the underlying buffer exposed by the memoryview object.
 | 
 | tobytes(...)
 | M.tobytes() -> bytes
 | 
 | Return the data in the buffer as a bytestring.
 | 
 | tolist(...)
 | M.tobytes() -> list
 | 
 | Return the data in the buffer as a list of elements.

In the new patch, I added docstrings for the data members and now the list of memoryview data descriptors looks as follows in pydoc:
 | ----------------------------------------------------------------------
 | Data descriptors defined here:
 | 
 | c_contiguous
 | A bool indicating whether the memory is C contiguous.
 | 
 | contiguous
 | A bool indicating whether the memory is contiguous.
 | 
 | f_contiguous
 | A bool indicating whether the memory is Fortran contiguous.
 | 
 | format
 | A string containing the format (in struct module style)
 | for each element in the view.
 | 
 | itemsize
 | The size in bytes of each element of the memoryview.
 | 
 | nbytes
 | The amount of space in bytes that the array would use in
 | a contiguous representation.
 | 
 | ndim
 | An integer indicating how many dimensions of a multi-dimensional
 | array the memory represents.
 | 
 | obj
 | The underlying object of the memoryview.
 | 
 | readonly
 | A bool indicating whether the memory is read only.
 | 
 | shape
 | A tuple of ndim integers giving the shape of the memory
 | as a N-dimensional array.
 | 
 | strides
 | A tuple of ndim integers giving the size in bytes to access
 | each element for each dimension of the array or None for C
 | contiguous.
 | 
 | suboffsets
 | A tuple of ndim integers used internally for PIL-style arrays
 | or None.

This should also be fixed in 3.2 (at least for those methods/members which are in 3.2).

I am going to commit this tonight. Stefan, please let me know if you have any comments. I copied most of the descriptions from ReST manual with a few minor changes. See shape/strides/suboffsets.

I've left a couple of comments. -- Personally I'd also prefer if all
docstrings go into a separate section. I always perceive docstrings
as noise that takes up precious vertical space, so for _decimal I even
banned them into docstrings.h.
I don't know if there's any kind of convention for that though.

On Sep 3, 2012, at 1:22 PM, Stefan Krah <report@bugs.python.org> wrote:
> Personally I'd also prefer if all
> docstrings go into a separate section. I always perceive docstrings
> as noise that takes up precious vertical space, so for _decimal I even
> banned them into docstrings.h.
> 
> I don't know if there's any kind of convention for that though.
I've seen two types of convention: a docs trying before function definition and docstring after function body. I prefer the first because the docstring doubles as a short comment describing the function that follows. If we put docstrings in a separate section, we may see comments above functions diverge from docstrings over time. 
On the other hand, this is not that important and consolidating the changes in one section will make 3.2 to 3.3 merge easier. I'll consolidate and wait for someone else to complain. :-)

> On the other hand, this is not that important and consolidating the changes in one section will make 3.2 to 3.3 merge easier. I'll consolidate and wait for someone else to complain. :-)
Thanks! I'm certain someone will complain, probably on python-dev right after
you commit. :)

New changeset c49f89261d65 by Alexander Belopolsky in branch '3.2':
Issue #15855: added docstrings for memoryview methods and data descriptors.
http://hg.python.org/cpython/rev/c49f89261d65 

New changeset 16a69ccff5ce by Alexander Belopolsky in branch 'default':
Issue #15855: added docstrings for memoryview methods and data descriptors (merge 3.2).
http://hg.python.org/cpython/rev/16a69ccff5ce 

New changeset ba2c1def3710 by Alexander Belopolsky in branch 'default':
Issue #15855: added docstrings for memoryview methods and data descriptors new in 3.3.
http://hg.python.org/cpython/rev/ba2c1def3710 

A few remaining comments:
1) shape being None for 0-d views in 3.2 is probably a bug. I did not mention that behavior in docstring.
2) "a N-dimensional array" typo was copied from ReST. Fixing it does not deserve a separate tracker entry, but I would like to review the whole section and add new/changed in 3.3 as necessary once we resolve (1) above.

> 1) shape being None for 0-d views in 3.2 is probably a bug.
Probably. I don't know whether it's worth fixing. Several test cases in ctypes
as well as in NumPy rely on it. So I guess we should just leave it for 3.2.
> 2) "a N-dimensional array" typo was copied from ReST. Fixing it does
> not deserve a separate tracker entry, but I would like to review the
> whole section and add new/changed in 3.3 as necessary once we resolve
> (1) above.
There are definitely some places where new/changed could be added
(e.g. the empty tuple for 0-d views is not mentioned).

New changeset 82ae284cd5f1 by Alexander Belopolsky in branch 'default':
Issue #15855: updated related manual entries.
http://hg.python.org/cpython/rev/82ae284cd5f1 

It looks like there is nothing left to do here and the issue was left open by mistake. If I'm wrong, someone can reopen it with a note as to what remains to be done (or open a new issue).