Why is _gci a private method?

[mwaskom]

I was trying to figure out how the plt.colorbar magic works to try and extend better support for colorbars in multi-panel seaborn figure objects. I figured out it all runs though the _gci methods on the figure and axes objects, which are very helpful. But why are they protected with a leading underscore? Is there a better way to generically apply a colorbar in an object-oriented context?

[WeatherGod]

This is probably better suited for the matplotlib-dev mailing list as this isn't a bug.

That said, while I was not involved with the design of this stuff, the only reason why we have gcf/gca and friends is because that's what Matlab has. Last I checked, gci is not a Matlab function, and such magical things really should be discouraged from common use, especially when its behavior can be difficult to test.

[tacaswell]

fig.colorbar(cmaped_artist, ...)

[tacaswell]

and you can pass an Axes object to colorbar rather than letting it create an axes and re-arrange you plot.

[mwaskom]

This is probably better suited for the matplotlib-dev mailing list as this isn't a bug.

I'm sorry I didn't realize the matplotlib issues tracker is explicitly limited to bugs.

That said, while I was not involved with the design of this stuff, the only reason why we have gcf/gca and friends is because that's what Matlab has. Last I checked, gci is not a Matlab function, and such magical things really should be discouraged from common use, especially when its behavior can be difficult to test.

Maybe don't close the issue then if you don't have a good answer?

[mwaskom]

fig.colorbar(cmaped_artist, ...)

Right, but the point is that seaborn is not always going to be able to predict what kind of artist is going to be useful for the colorbar. Given that matplotlib has the machinery to work that out by inspecting the object, I was wondering why that machinery is marked as private. It's very useful!

[WeatherGod]

I closed the issue because it isn't a bug. And I am sorry you think my
answer is not a good one, but as a general rule, we like to limit the
exposure of "magical" functions such as _gci(). We can further this
discussion on the mailing list.

On Fri, Jun 12, 2015 at 11:51 AM, Michael Waskom notifications@github.com
wrote:

This is probably better suited for the matplotlib-dev mailing list as this
isn't a bug.

I'm sorry I didn't realize the matplotlib issues tracker is explicitly
limited to bugs.

That said, while I was not involved with the design of this stuff, the
only reason why we have gcf/gca and friends is because that's what Matlab
has. Last I checked, gci is not a Matlab function, and such magical things
really should be discouraged from common use, especially when its behavior
can be difficult to test.

Maybe don't close the issue then if you don't have a good answer?

—
Reply to this email directly or view it on GitHub
#4517 (comment)
.

[mwaskom]

No thanks; I'm pretty sure you'd just respond to my email with "this isn't a question about matplotlib development".

[WeatherGod]

???

I am sorry, did I miss something somewhere? This is completely a question
about matplotlib development and the fact that I am asking you to post it
there should make it quite plain that that is where it belongs. I do not
understand the hostility I am sensing in your replies. To make it clear, my
closing of the issue was not intended to be hostile either, just a matter
of housekeeping. We have far too many issues open in our tracker and too
few people to manage them. The developers regularly field design and
architectural questions on the mailing list and so you will likely have a
more productive discussion there.

On Fri, Jun 12, 2015 at 11:57 AM, Michael Waskom notifications@github.com
wrote:

No thanks; I'm pretty sure you'd just respond to my email with "this isn't
a question about matplotlib development".

—
Reply to this email directly or view it on GitHub
#4517 (comment)
.

[tacaswell]

Right, but the point is that seaborn is not always going to be able to predict what kind of artist is going to be useful for the colorbar. Given that matplotlib has the machinery to work that out by inspecting the object, I was wondering why that machinery is marked as private. It's very useful!

I don't understand why seaborn can't predict this but mpl can. You can capture the artists created in your plotting functions and you either know ahead of time if you are going to expect color mapped artists back or you can introspect them and see what sub-classes ColorMappable.

For reference, this was added in e91c5a1 by @efiring