| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Thank you for opening your first PR into Matplotlib!
If you have not heard from us in a week or so, please leave a new comment below and that should bring it to our attention. Most of our reviewers are volunteers and sometimes things fall through the cracks.
You can also join us on gitter for real-time discussion.
For details on testing, writing docs, and our review process, please see the developer guide
We strive to be a welcoming and open project. Please follow our Code of Conduct.
Sorry, something went wrong.
|
Thanks for the fast work @nbarlowATI and for checking this works for the example in the issue. I'm unsure whether passing a single string will work at the moment. Could you check what happens if you pass hatch="\\"? This will also need some tests. Please see here for general guidance on testing. You might also like to look at the tests added at #24470, where a similar change was made for the pie method. Please mark this as "ready for review" when you are ready (things marked as draft often get overlooked). In the meantime, if you need help, feel free to ask questions here. Or you may prefer to ask them in our incubator gitter room. |
Sorry, something went wrong.
| colors = (axes._get_lines.get_next_color() for _ in y) | ||
|
|
||
| if hatch: | ||
| if isinstance(hatch, Iterable): |
There was a problem hiding this comment.
be careful because hatches can be multi-char strings, and strings are Iterable.
I think what you may want is
if isinstance(hatch, (str, None)):
hatch = itertools.cycle([hatch])
else:
hatch = itertools.cycle(hatch)I think that should handle even the None case (also " " is not a valid hatch pattern and is causing warnings)
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks, and good point! You're right about the strings being iterables, and I think your logic is the right choice (though I had to modify slightly because None doesn't count as a type so can't be used in isinstance).
Sorry, something went wrong.
There was a problem hiding this comment.
Ahh, str | None would work (but is py3.10+ only so we can't use it).
builtins.NoneType or type(None) would also work, but is used less commonly.
Type hints allow None as shorthand, but not isinstance, apparently.
Sorry, something went wrong.
|
It'll also need a whats new example - what you have here is fine and you can also use the what's new in #24470 as an example. ETA: also I'm psyched, this is great and we should vectorize all the things 😄 |
Sorry, something went wrong.
|
I was thinking perhaps this change is a good chance to introduce the following API (provided this is clear and acceptable):
|
Sorry, something went wrong.
I understand why you're asking for this but I'm concerned this is a bit magic cause this is not a thing we do for any variables (list of color vary by density). Also if there was support for this, it'd have to work for all the places that take a list of hatches. And I wonder if this would be better achieved via custom hatch objects? hatch=DensityHatch('x') which returns an iterator of increasing density - which actually may work currently given our API doesn't really care what type of iterator hatch is? |
Sorry, something went wrong.
No problem. I was just throwing the idea for the debate. I'm very much in favour of continuous improvement so even if there's a chance my proposal would be considered for implementation but hindered the current work, it's probably best to get out the current change (support for list of hatches) and then go back to the other ideas in the next iterations... |
Sorry, something went wrong.
|
I added a test in test_axes.py that compares a stackplot with a list of hatching styles with the result of usingfill_between with the same data and hatching styles. |
Sorry, something went wrong.
|
last thing left is fixing the stubtest by adding this variable - which I think is None | List[str] | str ? - to the type stub matplotlib/lib/matplotlib/streamplot.pyi Line 11 in e501543 |
Sorry, something went wrong.
| @@ -3792,12 +3792,15 @@ def spy( | |||
|
|
|||
| # Autogenerated by boilerplate.py. Do not edit as changes will be lost. | |||
There was a problem hiding this comment.
As the comment says, the signatures here are autogenerated
Sorry, something went wrong.
There was a problem hiding this comment.
Ah yes, sorry! I think I ran boilerplate.py myself in the hope of fixing the stub github action, as I didn't know about the .pyi file... Should I revert this commit, or will the autogeneration take care of it anyway?
Sorry, something went wrong.
There was a problem hiding this comment.
I think you are supposed run boilerplate.py yourself, and this comment is meant to indicate that you shouldn't manually edit the type hints here.
Sorry, something went wrong.
There was a problem hiding this comment.
🤦♀️ I think Ruth is right given I edited this file in my PR too and we never call boilerplate.py as part of our build/install process. Sorry & I'll open up a follow up issue on documenting how this is used!
Sorry, something went wrong.
| A sequence of hatching styles (see reference in | ||
| https://matplotlib.org/devdocs/gallery/shapes_and_collections/hatch_style_reference.html) |
There was a problem hiding this comment.
| A sequence of hatching styles (see reference in | |
| https://matplotlib.org/devdocs/gallery/shapes_and_collections/hatch_style_reference.html) | |
| A sequence of hatching styles. See :ref:`sphx_gallery_shapes_and_collections_hatch_style_reference.py |
Personal bias against parentheticals & we always cross-reference when possible so that the link goes to the tutorial in the same version of the docs
https://sphinx-gallery.github.io/stable/advanced.html#cross-referencing
But also double check that link by building the doc cause I may have done something wonky
Sorry, something went wrong.
There was a problem hiding this comment.
OK makes sense. For me, the above ':ref:' link didn't quite work in my locally built version of the docs, but I copied something very similar (using ':doc:') from the pie chart docstring, that seems to work.
Sorry, something went wrong.
There was a problem hiding this comment.
thank you for your patience w/ my "oh, another thing" 😅
Sorry, something went wrong.
There was a problem hiding this comment.
No problem (I'm a big fan of Columbo!), and thanks for your help! :)
Sorry, something went wrong.
There was a problem hiding this comment.
Yay, it's got code and tests and typing and a whats new 🥳
Slight optional wording suggestion, but I think it's good to go. Also do you want to rebase or do you want one of us to?
Sorry, something went wrong.
|
Thanks! Re: rebasing, it would be great if one of you could do it - I'm away for the next few days (but I could also do it when I'm back...) |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for your work on this @nbarlowATI. I just have one minor comment.
Sorry, something went wrong.
|
This will also need squashing down to one commit if you are confident to do so, otherwise we can handle that on merge. Edit: oops I see you already discussed that. |
Sorry, something went wrong.
|
Hi, I'm back online now, and happy to have a go at the rebase. Just to confirm, is the idea to both:
|
Sorry, something went wrong.
This one please! Since there are no conflicts between your branch and upstream/main, the ordering of your commits vs upstream/main's commits do not matter. We have some guidance here if you need it |
Sorry, something went wrong.
|
Don't add complication you don't need of course, but git rebase -i upstream/main is the command I always use. |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks @nbarlowATI and congratulations on your first PR in Matplotlib! We hope to hear from you again.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR summary
Closes #27146 this modifies stackplot.py to treat the hatch argument to stackplot in the same way as colors, i.e. if a list is provided, it will cycle through those hatch styles for the different data in the stack.
I believe the existing behaviour is preserved - if a single style (e.g. "x") is provided, this will be used for all elements of the stack, while if no "hatch" argument is passed, it will apply hatch style " " to all elements (though perhaps this isn't the best way of doing this?)
Using the example code in the original Issue from @pawjast :
fig, ax = plt.subplots( figsize=(10,6), facecolor="white", layout="constrained" ) fig.suptitle( "with hatching", fontsize=25, weight="bold" ) x = range(data.shape[1]) ax.stackplot( x, data, hatch=["x", "\\", "//", "-"] ) ax.set_xlim(0, 9) ax.set_ylim(0, 350)I get the following:

Let me know if this looks OK, and if so I can make a start on updating documentation and tests.
PR checklist