color argument to collections

Suggestion: we say, "A color can be specified as a string in

    > any of the following formats: standard color abbreviations,
    > html names, hex, or a floating point number between 0 and 1.
    > Or it can be given as a sequence of three numbers specifying
    > R,G,B on a scale from 0 to 1." Perfectly consistent and
    > understandable, and clear in the code: "if
    > is_string_like(c): convert it, else: pass it on as RGB.
    > This consistency then makes it easy to distinguish between,
    > and transparently handle, the case of a single color versus
    > 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

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

As for looks_like_color, I never use it (in fact was not aware of it
til you mentioned it). I think a function "is_colorlike" is a
potentially useful function, but as you say it is best implemented
with duck typing, something like

def is_colorlike(x):
    try: colorConverter.to_rgba(x)
    except: return False
    else: return True

JDH

For what its worth, I'll also drop my objection.

Darren

···

On Sunday 21 May 2006 15:26, John Hunter wrote:

    > Suggestion: we say, "A color can be specified as a string in
    > any of the following formats: standard color abbreviations,
    > html names, hex, or a floating point number between 0 and 1.
    > Or it can be given as a sequence of three numbers specifying
    > R,G,B on a scale from 0 to 1." Perfectly consistent and
    > understandable, and clear in the code: "if
    > is_string_like(c): convert it, else: pass it on as RGB.
    > This consistency then makes it easy to distinguish between,
    > and transparently handle, the case of a single color versus
    > 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

Darren Dale wrote:

···

On Sunday 21 May 2006 15:26, John Hunter wrote:

"Eric" == Eric Firing <efiring@...229...> writes:

   > Suggestion: we say, "A color can be specified as a string in
   > any of the following formats: standard color abbreviations,
   > html names, hex, or a floating point number between 0 and 1.
   > Or it can be given as a sequence of three numbers specifying
   > R,G,B on a scale from 0 to 1." Perfectly consistent and
   > understandable, and clear in the code: "if
   > is_string_like(c): convert it, else: pass it on as RGB.
   > This consistency then makes it easy to distinguish between,
   > and transparently handle, the case of a single color versus
   > 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

For what its worth, I'll also drop my objection.

Thanks. I will proceed.

Eric

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

(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

···

On 5/21/06, Eric Firing <efiring@...229...> wrote:

Darren Dale wrote:
> On Sunday 21 May 2006 15:26, John Hunter wrote:
>
>>>>>>>"Eric" == Eric Firing <efiring@...229...> writes:
>>
>> > Suggestion: we say, "A color can be specified as a string in
>> > any of the following formats: standard color abbreviations,
>> > html names, hex, or a floating point number between 0 and 1.
>> > Or it can be given as a sequence of three numbers specifying
>> > R,G,B on a scale from 0 to 1." Perfectly consistent and
>> > understandable, and clear in the code: "if
>> > is_string_like(c): convert it, else: pass it on as RGB.
>> > This consistency then makes it easy to distinguish between,
>> > and transparently handle, the case of a single color versus
>> > 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