[Matplotlib-users] Vectorized version of text()

[Brendan Barnwell]

On 2015-09-12 18:23, Thomas Caswell wrote:
> There is some work in this direction already
> (https://github.com/matplotlib/matplotlib/pull/4063).
>
> More generally, I was thinking about this problem earlier today!  One of
> the things that bokeh does really will is broadcast all the things.
> Because we have a huge code base I am biased towards decorators and
> higher-level functions to solve these sorts of things.  Would a function
> that looks like
>
> def broadcast_all_the_things(func, *args, static_kwargs=None, **kwargs):
>          kwarg_cycler = map(add, cycler(k, v) for k, v in kwargs)
>          ret = []
>          if static_kwargs is None:
>              static_kwargs = {}
>          for arg, kwarg in zip(zip(args), kwarg_cycler):
>              total_kwargs = {**kwarg_cycler, **static_kwargs}  # this
> works in 3.5!
>              ret.append(func(*arg, **total_kwargs))
>          return ret
>
> be useful / an acceptable solution?
>
> The call would look something like:
>
> broadcast_all_the_things(ax.text, x_vec, y_vec, s_vec,
> fontsize=font_size_vec, static_kwargs={'color':'r'})
>
> There clearly needs to be a bit more thought put into this (like to
> support automatic unpacking from a data kwarg), but I like the rough
> idea.  It might also make sense to provide a decorator to make easy to
> provide `bulk_*` functions in the mpl name spaces.

	That would be better than nothing.  The bulk_blah would be much better 
than a single generic do_in_bulk function.  When working interactively I 
often rely on IDE/shell features that let me, for instance, look at the 
docstring and argument signature of the function I'm calling, so it's 
helpful to have the function know what arguments it accepts and know 
their names, instead of showing me a generic *args, **kwargs signature.

	I do think it would be good, though, to devote some thought to 
vectorizing the arguments of existing API calls wherever possible.  That 
is, if there isn't an overarching principle for when function arguments 
should accept a sequence instead of a single value, we should formulate one.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown