Lazily resolve colors for Patches. #11711
Conversation
This is consistent with Line2Ds and avoids complications with
_original_{face,edge}color.
test_patch_color_none was removed as it doesn't make much sense anymore
(fixing it would just mean testing that mcolors.to_rgba is working as
expected).
8b4626a to
ec56a0c
Compare
|
I agree w. this change of behaviour. OTOH I think collections should get the same treatment to keep things consistent. The only problem with returning the user's version of the colors is that they are not programatically trivial to parse out. |
|
collections are a bit more complicated because there you probably do want to have some kind of caching for performance reasons (as colors can be big arrays). I have some idea of how to do it but would prefer that we first agree on whether this is the direction we want to go. |
|
Throwing in my 2 cents that lazy evaluation of the color cycle spec should be the goal. This stems from the concept that |
|
This should get some executive decision about whether is should be done before @anntzer rebases... I've put on the agenda for Monday... |
|
OK, I think we have decided that lazy evaluation is not wanted (and should probably be removed for line2d? |
|
yes |
See explanation in #11710 (which this closes).
This is consistent with Line2Ds and avoids complications with
original{face,edge}color.
test_patch_color_none was removed as it doesn't make much sense anymore
(fixing it would just mean testing that mcolors.to_rgba is working as
expected).
Also closes #11702; includes the test from #11703.
(We may also want to do the same thing with Collections.)
PR Summary
PR Checklist