<div dir="ltr">Andy,<div><br></div><div>This is exactly the right place to post things like this.</div><div><br></div><div>Fernando Perez has proposed something similar to me in person.  As part of the label data un-packing discussion there was talk of allowing users to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a square root function) which is sort of related to this.</div><div><br></div><div>What follows is a rather rambling brain dump of me thinking about this ;)</div><div><br></div><div>Do you want the functions to be evaluated at Artist creation time or Artist draw time? </div><div><br></div><div>If it is at creation time, see <a href="https://github.com/matplotlib/matplotlib/pull/4829">https://github.com/matplotlib/matplotlib/pull/4829</a> for how we implemented something similar for unpacking labeled data.  That might be a reasonable template for how to do this.  Would tooling to easily bind plotting functions to the computation be good enough?  For controlling any additional args/kwargs to the mapping function we can just use `partial`</div><div><br></div><div>If it is at _draw_ time, I am a bit more skeptical. But if you can change the x data, the rest of the data _should_ recompute so that would probably be a better way to do it long term, but will require much more invasive changes to the library.</div><div><br></div><div>We already have a fair number of mapping functions internally (ex, the whole transform stack and the data -> norm -> cmap chain), I wonder if there is a way to generalize any of that?</div><div><br></div><div>I am also a bit concerned that this will balloon quickly, for example, for people plotting histograms, they may want the yerr to be a function of the y-value (ex Poisson error), not the x-value.  The complexity required to express everything that would need to be done once we start to go down this road is a bit daunting.</div><div><br></div><div>I have been thinking for a while (like a year) about a massive API re-working (which I owe the list a long write up on!), I have heard you and will think about how to integrate this.</div><div><br></div><div>One other concern is that our top-level API is _too_ magical rather than not magical enough.</div><div><br></div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley <<a href="mailto:andy.buckley@cern.ch">andy.buckley@cern.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Not sure if this is the best place to post this, but I have an API<br>
suggestion: as well as iterables, mpl plotting functions could accept<br>
callable objects to generate y values, errors, etc..<br>
<br>
Specifically, I'm thinking that the list of x values would always need<br>
to be specified as an iterable like now, but that the other arguments<br>
which currently require an iterable of the same length as the xs could<br>
alternatively accept callables that are mapped on to the xs list. The<br>
presence of __iter__ or __call__ attributes could be used to determine<br>
which approach to use.<br>
<br>
I searched a bit and couldn't find any previous mention of this idea,<br>
and there are callable arguments already used in matplotlib. Thoughts?<br>
I'd be happy to help with implementation if there is any interest.<br>
<br>
Best wishes,<br>
Andy<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>