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
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