John, Collections would be easier to use if they did not
> have the restriction (from the docstring):
> All color args to a collection are sequences of rgba
> tuples
> It would be easy to remove this restriction; shall I do it,
> or is there a reason to leave the restriction in place?
> (The error message that results from violating the
> restriction is not helpful, and it would be as easy to
> remove the restriction as to improve the error handling.)
I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity. How would you interpret
color = (0.25, 0.5, 0.75, 1.0)
Is this one rgba color or 4 grayscales?
Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases. Just document what the behavior is, and everyone should
be happy. I think you could do the same for the linewidths, etc. Eg
if scalar, interpret as a single linewidth for all elements of the
collection?
Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?
JDH
John,
I think all the ambiguity that you mention below comes from one source: the use of a single float to indicate a greyscale. Do we really need this? It is not supported by colors.looks_like_color(). It could be replaced by a string representation of the float (e.g., '0.75') or by a more specific string, such as 'g0.75' or 'grey0.75'. I think this would be a big net gain for mpl. We lose a lot of flexibility, convenience, and consistency by allowing the float-is-grey form.
Eric
John Hunter wrote:
···
"Eric" == Eric Firing <efiring@...229...> writes:
> John, Collections would be easier to use if they did not
> have the restriction (from the docstring):
> All color args to a collection are sequences of rgba
> tuples
> It would be easy to remove this restriction; shall I do it,
> or is there a reason to leave the restriction in place?
> (The error message that results from violating the
> restriction is not helpful, and it would be as easy to
> remove the restriction as to improve the error handling.)
I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity. How would you interpret
color = (0.25, 0.5, 0.75, 1.0)
Is this one rgba color or 4 grayscales?
Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases. Just document what the behavior is, and everyone should
be happy. I think you could do the same for the linewidths, etc. Eg
if scalar, interpret as a single linewidth for all elements of the
collection?
Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?
JDH
I have used floats to indicate color in many of my own scripts. I think
changing this would have a pretty big impact on the users.
Darren
···
John,
I think all the ambiguity that you mention below comes from one source:
the use of a single float to indicate a greyscale. Do we really need
this? It is not supported by colors.looks_like_color(). It could be
replaced by a string representation of the float (e.g., '0.75') or by a
more specific string, such as 'g0.75' or 'grey0.75'. I think this would
be a big net gain for mpl. We lose a lot of flexibility, convenience,
and consistency by allowing the float-is-grey form.
Eric
John Hunter wrote:
"Eric" == Eric Firing <efiring@...229...> writes:
> John, Collections would be easier to use if they did not
> have the restriction (from the docstring):
> All color args to a collection are sequences of rgba
> tuples
> It would be easy to remove this restriction; shall I do it,
> or is there a reason to leave the restriction in place?
> (The error message that results from violating the
> restriction is not helpful, and it would be as easy to
> remove the restriction as to improve the error handling.)
I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity. How would you interpret
color = (0.25, 0.5, 0.75, 1.0)
Is this one rgba color or 4 grayscales?
Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases. Just document what the behavior is, and everyone should
be happy. I think you could do the same for the linewidths, etc. Eg
if scalar, interpret as a single linewidth for all elements of the
collection?
Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?
JDH
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Darren Dale wrote:
I have used floats to indicate color in many of my own scripts. I think
changing this would have a pretty big impact on the users.
Darren
Darren,
Float as greyscale, right?
Yes, I am concerned about breaking things, but maybe it is not too late to deprecate it, so that the transition could be made some time in the future. I think it is worth considering this carefully now, while we are still pre-1.0.
Eric
···
John,
I think all the ambiguity that you mention below comes from one source:
the use of a single float to indicate a greyscale. Do we really need
this? It is not supported by colors.looks_like_color(). It could be
replaced by a string representation of the float (e.g., '0.75') or by a
more specific string, such as 'g0.75' or 'grey0.75'. I think this would
be a big net gain for mpl. We lose a lot of flexibility, convenience,
and consistency by allowing the float-is-grey form.
Eric
John Hunter wrote:
"Eric" == Eric Firing <efiring@...229...> writes:
> John, Collections would be easier to use if they did not
> have the restriction (from the docstring):
> All color args to a collection are sequences of rgba
> tuples
> It would be easy to remove this restriction; shall I do it,
> or is there a reason to leave the restriction in place?
> (The error message that results from violating the
> restriction is not helpful, and it would be as easy to
> remove the restriction as to improve the error handling.)
I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity. How would you interpret
color = (0.25, 0.5, 0.75, 1.0)
Is this one rgba color or 4 grayscales?
Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases. Just document what the behavior is, and everyone should
be happy. I think you could do the same for the linewidths, etc. Eg
if scalar, interpret as a single linewidth for all elements of the
collection?
Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?
JDH
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Darren Dale wrote:
> I have used floats to indicate color in many of my own scripts. I think
> changing this would have a pretty big impact on the users.
>
> Darren
Darren,
Float as greyscale, right?
Yes, that's what I meant.
Yes, I am concerned about breaking things, but maybe it is not too late
to deprecate it, so that the transition could be made some time in the
future. I think it is worth considering this carefully now, while we
are still pre-1.0.
slightly off-topic: Will mpl ever go 1.0? That's not meant to be flippant. I
thought their was some pride in being beta.
···
On Saturday 20 May 2006 15:47, Eric Firing wrote:
>>John,
>>
>>I think all the ambiguity that you mention below comes from one source:
>>the use of a single float to indicate a greyscale. Do we really need
>>this? It is not supported by colors.looks_like_color(). It could be
>>replaced by a string representation of the float (e.g., '0.75') or by a
>>more specific string, such as 'g0.75' or 'grey0.75'. I think this would
>>be a big net gain for mpl. We lose a lot of flexibility, convenience,
>>and consistency by allowing the float-is-grey form.
>>
>>Eric
>>
>>John Hunter wrote:
>>>>>>>>"Eric" == Eric Firing <efiring@...229...> writes:
>>>
>>> > John, Collections would be easier to use if they did not
>>> > have the restriction (from the docstring):
>>>
>>> > All color args to a collection are sequences of rgba
>>> > tuples
>>>
>>> > It would be easy to remove this restriction; shall I do it,
>>> > or is there a reason to leave the restriction in place?
>>> > (The error message that results from violating the
>>> > restriction is not helpful, and it would be as easy to
>>> > remove the restriction as to improve the error handling.)
>>>
>>>I think it's fine to remove it, but note that you have to be careful
>>>to avoid ambiguity. How would you interpret
>>>
>>> color = (0.25, 0.5, 0.75, 1.0)
>>>
>>>Is this one rgba color or 4 grayscales?
>>>
>>>Because mpl accepts lots of different types of args for colors, there
>>>will probably be some ambiguous cases, thought these will be very rare
>>>corner cases. Just document what the behavior is, and everyone should
>>>be happy. I think you could do the same for the linewidths, etc. Eg
>>>if scalar, interpret as a single linewidth for all elements of the
>>>collection?
>>>
>>>Or were you intending to preserve the requirement that one pass
>>>sequences, but allow versatile color args in the sequence?
>>>
>>>JDH
>>
>>-------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job
>>easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>>Matplotlib-devel mailing list
>>Matplotlib-devel@lists.sourceforge.net
>>matplotlib-devel List Signup and Options
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd55@...143...
office: (607) 255-9894
fax: (607) 255-9001