Skip to content
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

quickplot should provide a show method #607

Closed
ajdawson opened this issue Jul 9, 2013 · 7 comments
Closed

quickplot should provide a show method #607

ajdawson opened this issue Jul 9, 2013 · 7 comments

Comments

@ajdawson
Copy link
Member

ajdawson commented Jul 9, 2013

Currently iris.plot provides a convenience show() method but iris.quickplot does not. This means that users making quickplot plots are forced to load another module in order to display them. A convenience show() method should be added to iris.quickplot also.

@niallrobinson
Copy link
Contributor

+1 - I've come up against this as well

@rhattersley
Copy link
Member

Just for completeness, quickplot does include a reference to matplotlib's pyplot module (which hosts the show() method), so you can do: qplt.plt.show().

@ajdawson
Copy link
Member Author

Yeah I suppose so, but I'm wary about encouraging qplt.plt.show() because I've seen things like this going on before: a = iris.cube.np.array([1,2,3,4,5]) 😢

I still think it would be nice for quickplot to have its own show, making it consistent with the standard matplotlib interface and the iris.plot interface. It doesn't really bloat the code and makes for a very comfortable and consistent interface for users.

@cpelley
Copy link

cpelley commented Jul 10, 2013

+1

@rhattersley
Copy link
Member

Yeah I suppose so, but I'm wary about encouraging qplt.plt.show() because I've seen things like this going on before: a = iris.cube.np.array([1,2,3,4,5]) 😢

😱 I was just playing devil's advocate with my previous post, but I didn't realise how devilish it could get!

My personal opinion is we shouldn't encourage things like qplt.plt.... In fact I'd be happier if plt didn't exist within the quickplot namespace at all - it's just an implementation detail and shouldn't form part of the public API.

I know I'm going off on a tangent somewhat, but this is a general issue. Most imports are implementation detail. As such it'd be more consistent if they were prefixed with an underscore, e.g. import itertools as _itertools and from iris.cube import Cube as _Cube. Hmm....

@ajdawson
Copy link
Member Author

You are absolutely right the imports are implementation details, but there are going to be a lot of underscores if you treat them that way! As long as you provide an adequate public interface that doesn't encourage this type of bad behaviour I don't think there is a problem.

@rhattersley
Copy link
Member

Indeed. The explosion of underscores might be why you don't see this idiom elsewhere. For now I'm just going to let the idea lurk in the back of my mind. But once it occurred to me I felt I ought to share. 😉

Anyway ... enough of tangents ...

iris.quickplot.show() 👍

rhattersley added a commit that referenced this issue Jul 16, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants