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

multi-colored text example #2561

Merged
merged 5 commits into from Nov 21, 2013
Merged

multi-colored text example #2561

merged 5 commits into from Nov 21, 2013

Conversation

ivanov
Copy link
Member

@ivanov ivanov commented Oct 30, 2013

as suggested over in #697, that example is being added to the gallery

@ivanov
Copy link
Member Author

ivanov commented Oct 30, 2013

here's what the resulting image looks like

rainbow_text

@mdboom
Copy link
Member

mdboom commented Oct 30, 2013

Why both png and jpg versions of the unicorn?

@ivanov
Copy link
Member Author

ivanov commented Oct 30, 2013

oops. the jpeg is the original, but IIRC we can't open jpegs natively, which is why I included the png.

let me work some git magic to remove the jpeg from the commits...

@ivanov
Copy link
Member Author

ivanov commented Oct 30, 2013

ok, removed the jpeg, so just the png now

from matplotlib import transforms
from matplotlib.cbook import get_sample_data

def rainbow_text(x,y,ls,lc,**kw):
Copy link
Member

Choose a reason for hiding this comment

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

could do with some spaces 😉

@pelson
Copy link
Member

pelson commented Oct 31, 2013

@ivanov - I love it. As you can see, you've got a bunch of really picky comments from me, but what else would you expect? 😉

Thanks for sharing!

@efiring
Copy link
Member

efiring commented Oct 31, 2013

I'm sorry, but as resident curmudgeon I have to report that although the example is clever and cute, I don't think it is appropriate for mpl.

@ivanov
Copy link
Member Author

ivanov commented Oct 31, 2013

@efiring is this because of the content? Because this is just an example, and we're not adding anything to mpl internals precisely because I don't think such functionality belongs in mpl.

@efiring
Copy link
Member

efiring commented Oct 31, 2013

@ivanov It is just the specific image file you chose to annotate that grates on me; having an example of how to manipulate text in this way is all to the good, entirely appropriate, and much appreciated.

@ivanov
Copy link
Member Author

ivanov commented Oct 31, 2013

I guess there aren't enough dolphins in swimming about in this example? 😉

Eric, thanks for chiming in with dissent. I appreciate and generally share in the curmudgeonry, and don't mind removing the image if need be. I just also like the history behind the dolphin example, so wanted to add a bit more to that legacy.

Unless others chime in with a strong preference for keeping it in, I'll go ahead and remove it.

@mdboom
Copy link
Member

mdboom commented Nov 14, 2013

@ivanov: We just discussed this on the hangout. Many of us like this and think it's funny, but we think we should err on avoiding potentially offensive images... so as cool as this is, we should probably remove it ;) Other than that, I have no objections on a technical level.

@ivanov
Copy link
Member Author

ivanov commented Nov 16, 2013

Ok, I've removed the image from git history here, glad you guys found it funny, I'll have to use that image elsewhere.

I have also made the changes that @pelson and @tacaswell requested. Here's the current, hopefully less offensive rendered version. Let me know if I need to change the text, too, but otherwise this is ready to be merged.

rainbow_text

@tacaswell
Copy link
Member

I think the def my_fun(ax, ...) pattern is one that we should be encouraging for user to use so we should show it in the examples.

@ivanov
Copy link
Member Author

ivanov commented Nov 16, 2013

I think the def my_fun(ax, ...) pattern is one that we should be encouraging for user to use

I disagree. Why should we be encouraging users to use that? It's very annoying to have to pass an axes argument, especially in cases (pretty much always?) where there is an implicit one that can be used, instead.

There is exactly one example where we have a function that takes an ax argument, and that also uses the optional kwarg approach, like the one I've taken here:
http://matplotlib.org/examples/specialty_plots/hinton_demo.html

@ivanov
Copy link
Member Author

ivanov commented Nov 16, 2013

Leaving an optional ax argument also keeps the call signature closer to actual plotting calls (like plt.text and ax.text)

@tacaswell
Copy link
Member

The problem with implicit axes is, very much like my comments, they involve too much hidden state ;)

If you only have one axes in one figure, that plt is great, but if you have more than one of either, the state machine infrastructure starts to turn into slightly unpredictable magic. I want to cite the apocryphal quote "guis make simple things easy and complex things impossible" and want to apply apply that to pyplot. It is great for interactive stuff, but should be used very sparingly (if at all) inside of functions.

As part of a larger discussion (that I think is going on with the re-ordering of the user guide?) I think we should push the OO interface more in the examples and documentation and de-emphasize the pyplot interface. Users are working in python, they are going to have to understand objects anyway, it will generate far less confusion in the long run (see links below) if we lead with the OO stuff. Once users have a very minimal model of the OO layers (1 or more Axes go in a Figure, data + text goes into Axes), we can then say "and plt will smooth over keeping track of some annoying details for you when you are working interactively". The way it seems to be pitched now (here I am responding more to the questions I see on SO, rather than what the docs actually say) is "here is plt, it's magic...just like MATLAB!" and then once users get outside of what plt can easily do they hit a brick wall and get frustrated.

The def f(ax, ...) is exactly the interface of the underlying function of ax.text (which means you can later trivially monkey patch your functions in if you want) and as you could probably guess from my rant above, I am not sold on emulating the pyplot functionality.

[1] http://stackoverflow.com/questions/16750333/how-do-i-include-a-matplotlib-figure-object-as-subplot/16754215#16754215

[2] http://stackoverflow.com/questions/18980915/embed-matplotlib-figure-in-larger-figure/18982141#18982141

Also http://www.python.org/dev/peps/pep-0020/

@ivanov
Copy link
Member Author

ivanov commented Nov 16, 2013

@tacaswell ok, I understand your reasons, and I think we'll just have to agree to disagree :)

I'm more interested in the interactive usage of plotting functions, and not in monkey patching Axes to use them, and making ax as the first required positional argument makes using such a plotting function different from their plt and ax relatives. In other words:

rainbow_text(x, y, strings, colors)

looks more like either:

ax.text(x, y, some_string)
plt.text(x, y, some_string)

Making ax the first argument makes sense only for a plotting function that plots to only one axes. What about having three subplots? Optional keyword arguments isn't a matter of hiding anything magical, this isn't a case of "explicit is better than implicit" because following such a position to its logical conclusion, we shouldn't have default values for arguments at all.

@ivanov
Copy link
Member Author

ivanov commented Nov 20, 2013

ok, i'll go ahead and merge this tomorrow unless i hear otherwise

@ivanov
Copy link
Member Author

ivanov commented Nov 21, 2013

ok, fingers crossed, merging.

ivanov added a commit that referenced this pull request Nov 21, 2013
@ivanov ivanov merged commit 6b1d8e1 into matplotlib:master Nov 21, 2013
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.

None yet

5 participants