On 06/02/2010 01:20 PM, Benjamin Root wrote:
>
>
> On Wed, Jun 2, 2010 at 10:26 AM, John Hunter <jdh2...@gmail.com
> <mailto:jdh2...@gmail.com>> wrote:
>
>     On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root <ben.r...@ou.edu
>     <mailto:ben.r...@ou.edu>> wrote:
>      > I am curious as to why bar() should even be acting like
>     errorbar().  As a
>      > user, I would expect bar() to do bar graphs and errorbar() to do
>     error bar
>      > graphs.  Is there some sort of use-case that I am missing where
>     it makes
>      > sense to generate errorbars from a bar() function?

See barchart_demo.py.  I don't use barcharts myself, but I can imagine 
that if I did, I might want errorbars on them.

>
>     Some of this stuff is just really old (circa 2003).  When you have
>     just a few users and someone sends you a patch, you tend to accept it
>     :-)
>
>     First we had bar, then we had errorbar, and someone wanted the
>     convenience of easily adding errorbars to bar plots.  Over time, these
>     conveniences have grown into a fairly complex interface (xerr, yerr,
>     asymmetric errors).  So it has grown more organically than by design
>     and some rationalization and normalization of functionality would be a
>     good thing.  We have to balance that with the downsides of code
>     breakage, however.
>
> I kinda figured something like that was the case.  I am just cautious
> about additional "organic" development of these functions.  I have
> encountered some functions where it was a bug that the function did not
> pass on the kwargs, and others where it wasn't a bug.  Does the approach
> of using a separate dict called error_kw fit in with some sort of
> overall design/best practices or might there be a better way to approach
> this.

It is precedented--see the relatively new subplots command, and 
Axes.text, which has had a fontdict kwarg for a long time.

I don't know of a better way of handling this sort of thing.  Perhaps it 
could be used more frequently and consistently within mpl.

Organic growth, with its faults and its advantages, is inherent in 
projects like mpl--and even in commercial products like Matlab.

mpl has only a little bit of written coding guidance.  See 
http://matplotlib.sourceforge.net/devel/coding_guide.html, most of which 
is not actually about coding.

>
> I merely ask because I am quite new here and I am curious about what
> style we want for our code.  Maybe we should consider some sort of
> special universal (for matplotlib) module that does special handling of
> kwargs?  I am just throwing out some thoughts.

You are welcome to propose something, but to have a chance of adoption 
it will need to be something that, for the most part, doesn't break 
users' code.

Eric

>
> Ben Root

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to