Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve docstring of Axes.pcolor #11317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 28, 2018
Merged

Conversation

timhoffm
Copy link
Member

PR Summary

As part of #10148: Docstring update for Axes.pcolor.


Notes
-----

**Masked arrays**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does numpydoc not support lower-level headings?

Masked arrays
~~~~~~~~~~~~~

(dunno)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. If you try this, numpydoc simply swallows the lower-level headings.

I think structuring with bold paragraphs is the best one can do.

of the vertices surrounding ``C[i,j]`` (*X* or *Y* at
``[i, j], [i+1, j], [i, j+1], [i+1, j+1]``) is masked, nothing is
plotted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as there's no heading there I'm not sure this anchor is correct (see above re lower headings)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does work the id is attached to the paragraph:

<p id="axes-pcolor-grid-orientation"><strong>Grid orientation</strong></p>

@@ -5268,62 +5268,69 @@ def _pcolorargs(funcname, *args, allmatch=False):
def pcolor(self, *args, alpha=None, norm=None, cmap=None, vmin=None,
vmax=None, **kwargs):
"""
Create a pseudocolor plot of a 2-D array.
Create a pseudocolor plot of a 2-D array using quadrilaterals.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not convinced "using quadrilaterals" really helps here (and yes I know how pcolor is implemented).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need some sort of addition to differentiate it from imshow and matshow. A better wording is welcome.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its explained below - I think the differentiation is useful. OTOH to me the main difference w/ imshow is that the lateral and vertical spacing can be non-even (as opposed to distorted grids.)

Copy link
Member Author

@timhoffm timhoffm May 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively I could do "Create a pseudocolor plot with a non-regular rectangular grid." Is that more helpful?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that wording!

@@ -5268,62 +5268,69 @@ def _pcolorargs(funcname, *args, allmatch=False):
def pcolor(self, *args, alpha=None, norm=None, cmap=None, vmin=None,
vmax=None, **kwargs):
"""
Create a pseudocolor plot of a 2-D array.
Create a pseudocolor plot of a 2-D array using quadrilaterals.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its explained below - I think the differentiation is useful. OTOH to me the main difference w/ imshow is that the lateral and vertical spacing can be non-even (as opposed to distorted grids.)

pcolor can be very slow for large arrays; consider
using the similar but much faster
:func:`~matplotlib.pyplot.pcolormesh` instead.
*X* and *Y* can be used to specify the corners of the quadrilatals.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: quadrilaterals

@@ -5338,39 +5345,46 @@ def pcolor(self, *args, alpha=None, norm=None, cmap=None, vmin=None,
Other Parameters
----------------
antialiaseds : bool, optional, default: False
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow, is this really the parameter name? Thats terrible!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we have this pluralization scheme in some places, see e.g. LineCollection: colors, edgecolors, antialiaseds, ... Not really great and IMO not really necessary to pluralize, but it's the way it is now.

the row number as ``Y``, increasing up; hence it is plotted the way the
array would be printed, except that the ``Y`` axis is reversed. That
is, ``C`` is taken as ``C`` (y, x).
The grid orientation follows the MATLAB convention: an array *C* with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't particularly like this note, and find it confusing as written. Can we improve it while here?

"""
An array *C* with shape (nrows, columns) is plotted with the column number *X* 
and the row number as *Y*.  
"""

suffices in my opinion. I don't understand why anyone would think that y[j] doesn't correspond to C[j, i] so the only ambiguous orientation is if C is organized as C[j, i] or C[i, j].

Copy link
Member Author

@timhoffm timhoffm May 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Significantly shortend to:

The grid orientation follows the standard matrix convention: An array
C with shape (nrows, ncolumns) is plotted with the column number as
X and the row number as Y.

Removed also the whole example stuff as it's more confusing than helpflul.

but Matplotlib displays the last row and column if ``X`` and ``Y`` are
not specified, or if ``X`` and ``Y`` have one more row and column than
``C``.
**Difference to MATLAB pcolor()**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again:

Handling of pcolor end-cases

pcolor displays all columns of C if X and Y are not specified, or if X and Y have one more column than C. If X and Y have the same number of columns as C then the last column of C is dropped. Similarly for the rows.

@@ -5268,62 +5268,69 @@ def _pcolorargs(funcname, *args, allmatch=False):
def pcolor(self, *args, alpha=None, norm=None, cmap=None, vmin=None,
vmax=None, **kwargs):
"""
Create a pseudocolor plot of a 2-D array.
Create a pseudocolor plot of a 2-D array using quadrilaterals.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that wording!

@anntzer anntzer added this to the v3.0 milestone May 28, 2018
@anntzer anntzer merged commit 22bc89c into matplotlib:master May 28, 2018
@timhoffm timhoffm deleted the doc-axes-pcolor branch May 28, 2018 21:23
@timhoffm
Copy link
Member Author

@meeseeksdev backport to v2.2.x

@jklymak
Copy link
Member

jklymak commented May 28, 2018

...we aren't backporting *.py files...

The only changes to be backported to 2.2.N-doc are changes to doc, examples, 
or tutorials. Any changes to lib or src should not be backported to this branch.

@timhoffm
Copy link
Member Author

timhoffm commented May 28, 2018

That does only hold for the branch v2.2-doc. I'm quite strongly for backporting pure docstring updates to 2.2.x. It will be around for quite some time and definitively deserves the docstring improvements.

We can discuss if I should backport this to v2.2.x or v2.2-doc. But I really want to backport this somehow.

@jklymak
Copy link
Member

jklymak commented May 28, 2018

I'm not at all the final say on these things, so please feel free to argue up the chain... But I think 2.2.x is just for regressions and other important bug fixes. I don't think we want to also be merging in a bunch of doc string changes. I agree they are hugely helpful, but folks have managed to muddle through with the old docs so I personally don't think its critical that they be backported. But I don't actually do the backporting...

jklymak added a commit that referenced this pull request May 29, 2018
@QuLogic QuLogic modified the milestones: v3.0, v2.2.3 May 29, 2018
The default ``antialiaseds`` is False if the default
``edgecolors="none"`` is used. This eliminates artificial lines
The default *antialiaseds* is False if the default
*edgecolors*\ ="none" is used. This eliminates artificial lines
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't run the tests wth this line: SyntaxError: invalid escape sequence \

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strange. This is the recommended way:

 Use a backslash escaped space to work around that: thisis\ *one*\ word.

The docs itself look fine:
https://matplotlib.org/devdocs/api/_as_gen/matplotlib.axes.Axes.pcolor.html?highlight=pcolor#matplotlib.axes.Axes.pcolor

Why is the test inspecting the docstring at all? Do we have some doctests somewhere that need to be run?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a syntax error for me on one machine, but not on another. Grrrr. Maybe I have a messed up install on the other machine (which I can't access right now, of course).

Appending a r""" docstring """ makes it work again on the other machine.

Copy link
Member

@QuLogic QuLogic May 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timhoffm The recommended way you cite is for Sphinx, while @jklymak's error is coming from Python. The backslash escape for Sphinx is on the text that it sees, which is either a reST file or a docstring (extracted to a reST file by auto-something), but in order to place the backslash in the docstring, you also need to escape it for Python. So you need to double-escape or make it a raw string.

As to why @jklymak only sees it on one machine, maybe it's tests.py vs pytest? The former turns these deprecation warnings into errors. Also, the warnings are only raised on Python 3.6+.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh. Thanks @QuLogic : python tests.py does not work and gives the Syntax Error. py.test works. Thats what I get for just hitting ^R for the last time I ran the tests - obviously on one machine I mentally upgraded to py.test and the other I haven't 😉...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants