matplotlib-devel Mailing List for matplotlib

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
    >> def is_scalar(obj): try: obj+1 except TypeError: return False
    >> else: return True

    Jouni> This seems to have broken axes.legend(), which for some
    Jouni> reason calls flatten(handles), where handles contains
    Jouni> instances of classes like lines.Line2D, which fail the new
    Jouni> is_scalar test. I don't see why the list should need
    Jouni> flattening, except if the user passes in a non-flat list.

Oh, I see.  Apparently is_scalar was a badly named function.  I'm
going to temporarily revert to the old behavior and then do a cleanup
and rename later -- after testing this time :-)

JDH

John Hunter <jdh...@ac...> writes:

> I just looked in cbook and we did indeed have an is_scalar function
> but it looked broken so I replaced it with
>
> def is_scalar(obj):
>     try: obj+1
>     except TypeError: return False
>     else: return True

This seems to have broken axes.legend(), which for some reason calls
flatten(handles), where handles contains instances of classes like
lines.Line2D, which fail the new is_scalar test. I don't see why the
list should need flattening, except if the user passes in a non-flat
list.

-- 
Jouni

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:

    Fernando> Sure, your call.  Safety above convenience is a good
    Fernando> overall mantra.

There is a hybrid approach, but it gets away from the neat and tidy
approach suggested by Eric.  If any of the args in the tuple are
greater than one, we could assume it is 0..255, else assume 0..1.  But
I think consistency may trump convenience here.

JDH 

On 5/21/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Fernando" =3D=3D Fernando Perez <fpe...@gm...> writes:
>
>     Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
>     Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.
>
> My worry here is that it is pretty common to do something like
>
>   red =3D 1,0,0
>
> which in your system would be interpreted as a int tuple and hence in
> the 0..255 range.  It may be easier for people to divide by 255.0 when
> they have vals in the 0..255 range than it is for them to remember to
> use ints and float consistently.

Sure, your call.  Safety above convenience is a good overall mantra.

Cheers,

f

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:

    Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
    Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.

My worry here is that it is pretty common to do something like

  red = 1,0,0

which in your system would be interpreted as a int tuple and hence in
the 0..255 range.  It may be easier for people to divide by 255.0 when
they have vals in the 0..255 range than it is for them to remember to
use ints and float consistently.

JDH

On 5/21/06, Eric Firing <ef...@ha...> wrote:
> Darren Dale wrote:
> > On Sunday 21 May 2006 15:26, John Hunter wrote:
> >
> >>>>>>>"Eric" =3D=3D Eric Firing <ef...@ha...> writes:
> >>
> >>    Eric> Suggestion: we say, "A color can be specified as a string in
> >>    Eric> any of the following formats: standard color abbreviations,
> >>    Eric> html names, hex, or a floating point number between 0 and 1.
> >>    Eric> Or it can be given as a sequence of three numbers specifying
> >>    Eric> R,G,B on a scale from 0 to 1."  Perfectly consistent and
> >>    Eric> understandable, and clear in the code: "if
> >>    Eric> is_string_like(c): convert it, else: pass it on as RGB.
> >>    Eric> This consistency then makes it easy to distinguish between,
> >>    Eric> and transparently handle, the case of a single color versus
> >>    Eric> a sequence of colors.
> >>
> >>OK, you sold me.  I hadn't thought it through to see it was either a
> >>string, RGB/A.  I like the simplicity of this.  So I'm +1 for your
> >>suggestion with a deprecation period where we check for a scalar

As a minor comment, for the sake of completeness wouldn't it be nice to all=
ow

(R,G,B).float_tuple -> floats in the 0...1 range
(R,G,B).int_tuple -> floats  in the 0..255 range.

?

It's extremely common to see 0..255 specifications for colors.

Cheers,

f