I just took a look at bar() and errorbar().  bar() has linewidth and uses it
properly (I believe), except in the case where one specifies yerr/xerr (it
doesn't pass on kwargs nor does it apply the linewidth parameter).

Then looking at errorbar(), there is a kwarg called 'elinewidth' which
superceeds 'linewidth' if it is set.  Yet, I see no other use of
'elinewidth', only 'linewidth' in a dict called lines_kw.  I am not sure if
I see the point in having a parameter called 'elinewidth' (unless one wanted
to make a distinction between the width of the bar's lines and the width of
the line for the caps?), but that might be a side-issue.

I am not convinced that adding a dictionary argument to bar() would make
much sense.  Why not simply pass the kwargs to errorbar()?  That way, if one
wanted to use yerr/xerr, they could also include elinewidth and others if
they wish (or, even better, let linewidth and other parameters go back
through since those represent the user's intention in the first place).

Just my two cents,
Ben Root

On Tue, Jun 1, 2010 at 6:35 PM, Eric Firing <efir...@hawaii.edu> wrote:

> On 06/01/2010 01:17 PM, Fernando Perez wrote:
> > Hi all,
> >
> > I just spent some time digging through the matplotlib code, and I see
> > that the errorbar line width argument isn't passed through to the
> > underlying call.  In axis.bar, we have this code:
> >
> >          if xerr is not None or yerr is not None:
> >              if orientation == 'vertical':
> >                  # using list comps rather than arrays to preserve unit
> info
> >                  x = [l+0.5*w for l, w in zip(left, width)]
> >                  y = [b+h for b,h in zip(bottom, height)]
> >
> >              elif orientation == 'horizontal':
> >                  # using list comps rather than arrays to preserve unit
> info
> >                  x = [l+w for l,w in zip(left, width)]
> >                  y = [b+0.5*h for b,h in zip(bottom, height)]
> >
> >              self.errorbar(
> >                  x, y,
> >                  yerr=yerr, xerr=xerr,
> >                  fmt=None, ecolor=ecolor, capsize=capsize)
> >
> > while errorbar has this signature:
> >
> >      def errorbar(self, x, y, yerr=None, xerr=None,
> >                   fmt='-', ecolor=None, elinewidth=None, capsize=3,
> >                   barsabove=False, lolims=False, uplims=False,
> >                   xlolims=False, xuplims=False, **kwargs):
> >
> > For a poster, we wanted thicker errorbars drawn and had to resort to:
> >
> > plt.rcParams['lines.markeredgewidth'] = 2
> > plt.rcParams['lines.linewidth'] = 2
> >
> > and reverting back to normal width after making the errorbar calls.
> > Should I file a ticket about this, or are such fine-tuning tasks
> > considered as fair game for rcParams manipulations?
>
> No, that seems like a terrible kluge--not at all what rcParams is for.
> bar, errorbar, hist could use some major refactoring.  In the meantime,
> since bar simply calls errorbar, it seems to me that the solution is for
> bar to take a kwarg, say "errorkw", which is a dict that will be passed
> to errorbar via **errorkw, and that can have any valid errorbar kwargs
> in it.  There is some precedent for this sort of thing, and I find it a
> useful way of keeping kwargs from getting out of control when one is
> making complicated compound plots.
>
> If there is no objection, I will do it.
>
> Eric
>
> >
> > I'm happy to file the ticket, I just don't want to create unnecessary
> > noise if the rcparams is meant to be 'the way' to do it.
> >
> > Cheers,
> >
> > f
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
------------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to