Thread: [matplotlib-devel] barh vs. bar(orientation='horizontal')

Hi,

What is the reason for having both barh and bar, when the latter
accepts the orientation='horizontal' argument? I am asking because of
sf bug #1669506, which is about hist(orientation='horizontal') not
working because it passes a log kwarg to barh.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jouni K. Seppänen wrote:
> Hi,
> 
> What is the reason for having both barh and bar, when the latter
> accepts the orientation='horizontal' argument? I am asking because of
> sf bug #1669506, which is about hist(orientation='horizontal') not
> working because it passes a log kwarg to barh.
> 

I didn't do it--but it looks like the reason is that having barh as a 
separate method permits a more natural order of arguments without 
introducing more complexity in the argument handling.

Vertical bars take left, height, width, bottom;
barh takes bottom, width, height, left.

Handling this difference with all possible combinations of *args and 
**kwargs would be complex; the present method, using a separate name 
(barh), is nice and simple.

Looks like barh just needs to take a **kwargs (which could replace most 
of the present listed kwargs; or add a log kwarg to the list) and pass 
it along to bar.  You are taking care of this?

Eric

On 3/2/07, Eric Firing <ef...@ha...> wrote:


> I didn't do it--but it looks like the reason is that having barh as a
> separate method permits a more natural order of arguments without
> introducing more complexity in the argument handling.

barh was originally added for compatibility with matlab and on a user
request.  I think the kwarg was added to bar to support easy calling
for functions that use bar (eg hist) but may also want to configure
the orientation.

Eric Firing <ef...@ha...> writes:

> Looks like barh just needs to take a **kwargs (which could replace most 
> of the present listed kwargs; or add a log kwarg to the list) and pass 
> it along to bar.  You are taking care of this?

I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
This does change the behavior for people who were giving positional
arguments to barh, but they do get an error message.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/3/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:

> I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
> This does change the behavior for people who were giving positional
> arguments to barh, but they do get an error message.

Since this changes the API, albeit minimally, make sure these changes
are documented in the API_CHANGES file.  Thanks for working on this.

JDH

"John Hunter" <jd...@gm...> writes:

>> I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
>
> Since this changes the API, albeit minimally, make sure these changes
> are documented in the API_CHANGES file.  Thanks for working on this.

Done. Should the function signature in the docstring of barh be
changed as well? I think listing the possible keyword arguments and
their defaults is valuable in the help text, but the signature could
make people think they can use positional arguments.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/3/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:

> Done. Should the function signature in the docstring of barh be
> changed as well? I think listing the possible keyword arguments and
> their defaults is valuable in the help text, but the signature could
> make people think they can use positional arguments.

The call signature in the docstring should certainly be changed to
match the new signature.  Also, take a look at the kwdocd stuff we
have to see if you can make that work for the keyword args.  See
Axes.plot for an example, where we interpolate the Line2D keyword arg
docstring into the __doc__ attribute.

Thanks,
JDH

"John Hunter" <jd...@gm...> writes:

> The call signature in the docstring should certainly be changed to
> match the new signature.  

Ok. I synced the docstrings of bar and barh.

> Also, take a look at the kwdocd stuff we have to see if you can make
> that work for the keyword args.

It was already being used for Rectangle properties in the bar
docstring, so I made the barh docstring use it as well. We could
separate some of the shared documentation of bar and barh into a
constant substituted into both docstrings, I'm not sure if it would be
a net win.

Another bug related to bar and barh is #1200213:

  http://sourceforge.net/tracker/index.php?func=detail&aid=1200213&group_id=80706&atid=560720
  http://thread.gmane.org/gmane.comp.python.matplotlib.devel/648

There are really three problems listed: that bar and barh have
different defaults for what is now the align argument; that the first
two arguments to barh were in illogical order; and that bar has the
yerr argument before xerr.

According to the discussion about the first problem, barh used to
interpret the y coordinates as the centers of the bars, not the edges,
which is not true today, as both bar and barh default to align='edge'.
It seems that this was eventually resolved in a direction opposite to
that suggested in the discussion at that time.

The second problem seems to have been fixed, and I'm not convinced
that the third one is really a problem. I suppose the bug could be
closed?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks