8000 Make Axes.stem take at least one argument. by dmcdougall · Pull Request #1139 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Make Axes.stem take at least one argument. #1139

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 5 commits into from
Jan 4, 2013

Conversation

dmcdougall
Copy link
Member

When it takes only one, the abscissae default to np.arange(len(y))

This is my attempt at addressing #331.

"""
Create a stem plot.

Call signature::
Valid call signatures::
Copy link
Member

Choose a reason for hiding this comment

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

This change makes this docstring inconsistent with almost all others I am aware of. My feeling is that "Valid call signatures" should be reverted to "Call signature".

Copy link
Member

Choose a reason for hiding this comment

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

Probably the closest thing would be the docstring for plot.

@dmcdougall
Copy link
Member Author

The method pcolor has two call signatures, so I just copied that. Thanks for pointing out the inconsistency.

@mdboom
Copy link
Member
mdboom commented Aug 28, 2012

This is a nice fix.

@efiring
Copy link
Member
efiring commented Sep 2, 2012

@mdboom, is this waiting for master to switch to 1.3?

@pelson
Copy link
Member
pelson commented Sep 2, 2012

Does it need a changelog entry?

@efiring
Copy link
Member
efiring commented Sep 2, 2012

Or better, api_changes.rst, if it is targeted for 1.2. If it missed the freeze and is therefore delayed until 1.3, then it is just as well to wait on the documentation changes, since they will likely need to be rebased anyway if done now. I'm just not clear on what can be merged now, and what should wait. I don't like having this PR backlog.

@dmcdougall
Copy link
Member Author

Ok, no problem. I will wait for further instruction :) As always, thanks for the feedback, you guys are really helpful.

@dmcdougall
Copy link
Member Author

What needs to be done here?

@dmcdougall
Copy link
Member Author

I updated the CHANGELOG. Let me know if there's anything else I can do.

@WeatherGod
Copy link
Member

This change can break code. Consider the following:

plt.stem(x, y, 'r--')

This was a perfectly valid call before that will no longer work.

@dmcdougall
Copy link
Member Author

@WeatherGod Thank you for trying this. I believe I have fixed this now. I also added a small test to check the kwargs as well, nothing huge. Just sanity checks.

try:
second = np.asarray(args[1], dtype=np.float)
x, y = y, second
except:
Copy link
Member

Choose a reason for hiding this comment

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

At the very least, catch Exception, but I would rather catch IndexError and whatever else might come from numpy (ValueError, maybe?)

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, I wanted to catch both so didn't specify -- perhaps catching Exception also catches some magical python ponies that I am unaware of?

Copy link
Member Author

Choose a reason for hiding this comment

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

The IndexError comes from args[1] being out of bounds. The ValueError comes from the casting to np.float being invalid. This is the case in your example of stem(x, 'r--').

Copy link
Member

Choose a reason for hiding this comment

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

If you want to catch both, then do except (IndexError, ValueError):. There is a difference between except: and except Exception:. See here: http://docs.python.org/2/howto/doanddont.html#except

Copy link
Member Author

Choose a reason for hiding this comment

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

That's helpful -- thank you!

try:
basefmt = kwargs.pop('basefmt', args[2])
except IndexError:
basefmt = kwargs.pop('basefmt', 'r-')
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 don't like this big try/except block. Is there a better way of doing this?

Copy link
Member

Choose a reason for hiding this comment

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

Just a thought... just how different are the call signatures for stem() and
plot()? Perhaps we can utilize the same mechanism for processing arguments?

@dmcdougall
Copy link
Member Author

Finally got some time to look at this. I did some method chasing and made the following three observations:

  1. Axes.plot(self, *args, **kwargs) calls self._get_lines(*args, **kwargs)
  2. self._get_lines = _process_plot_var_args(self)
  3. _process_plot_var_args is a class to do a bunch of heavy lifting for the args and kwargs passed to plot

There's quite a bit of heavy lifting done inside the _process_plot_var_args class. I guess I'm just not really sure how to use it effectively. I guess the end goal would be to have Axes.stem just make a call to self._get_lines and proceed with the returned line's properties.

I'll play and see what I can come up with over the weekend.

@dmcdougall
Copy link
Member Author

Ok, I've been playing a little bit with this. Basically, the way stem works at the moment is to parse a bunch of stuff and pass the baseline, markers, and stemlines all to plot. Then the three resulting line collections are returned as part of a StemContainer for easy post-processing.

Now, I think what @WeatherGod is suggesting is to basically pass everything to plot in a single call. While that is totally possible due to plot's ninja argument handling skills, I'd still have to parse the list of lines returned from plot and put them into a StemContainer to preserve the return type of stem (presumably, preserving the return type of stem is desirable since it doesn't break backwards compatibility). That is fine and dandy and is probably a good way to refactor the stem function to make only one call to plot. However, I see no other benefit to doing that over what is currently implemented in this PR. I still have to pop the kwargs to stem and get the defaults set correctly like I have done here, the only difference is, by refactoring to a single call to plot, extra foo needs to be done to process the stuff returned from plot and massage it into StemContainer.

I guess the question is: is it worth it? The way it is currently, with three separate calls to plot, it's very easy to keep the marker, base, and stems separate and lump them together into a StemContainer. I think I prefer this approach. Others may disagree.

@WeatherGod I'd especially like your opinion on this summary since you were the one to suggest this originally.

@dmcdougall
Copy link
Member Author

Actually, I do have an idea of how to improve this. I'll report back shortly.

@dmcdougall
Copy link
Member Author

Scratch that; my idea didn't work.

@WeatherGod
Copy link
Member

yeah, looking again, it is probably not worth it to go that unified plot route.

@dmcdougall
Copy link
Member Author

@WeatherGod Depends what you want out of the code. I can see benefits to both approaches, however I think this one is probably the most appropriate.

This is fine to merge, in my opinion.

@dmcdougall
Copy link
Member Author

Can someone push the green button, please? :)

mdboom added a commit that referenced this pull request Jan 4, 2013
Make Axes.stem take at least one argument.
@mdboom mdboom merged commit 3b649cb into matplotlib:master Jan 4, 2013
@dmcdougall dmcdougall deleted the stemarg branch January 4, 2013 20:42
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.

5 participants
0