BUG/API : fix color validation #4193
Conversation
|
The original idea seems to have been that None could be used in the matplotlibrc file to mean the object None; your patch does not permit that. When the matplotlibrc file is read, everything starts out as a string, and that is the way it is passed to the validator. It is not the object None, so it will be passed on to the color validator and converted to 'None', which is not what was intended. This will happen if the user uncomments the line in the matplotlibrc template. Very confusing. The attempt to use None here is a mistake; or maybe the mistake, long ago, was using 'none' to mean no color. Instead of None, one could use "from_axes"; then |
|
An alternative to "from_axes" would be "inherited". |
|
Ahhh, I understand my confusion now. On Wed, Mar 4, 2015, 21:26 Eric Firing notifications@github.com wrote:
|
tacaswell
force-pushed
the
fix_color_rc
branch
2 times, most recently
from
636003a
to
174499e
Compare
Possible fix for matplotlib#4192. This adds a new validation (validate_color_or_None) method for color which allows None and restores `validate_color` to fail on None. This will allow selected color rcparams to be `None` (not `'None'`) which the library should interpret as "don't use this rcparam".
Attempt to implement 'inherited' rcparams, that is rcparams that are only used if they are non-default. Re-introduces feature introduced in matplotlib#3792 /92e608d655f1fa667fdf5bc3e99f950eb08f7c42 and reverted in c90469b
|
@efiring Try number 3 at fixing this. |
|
attn @mrkrd |
|
@efiring up or down on this? |
|
I like it. |
BUG/API : fix color validation
FIX : rcParams legend.facecolor and edgecolor never being used cleans up #4193
Possible fix for #4192.
This adds a new validation (validate_color_or_None) method for color
which allows None and restores
validate_colorto fail on None.This will allow selected color rcparams to be
None(not'None')which the library should interpret as "don't use this rcparam".
Not 100% that this fixes all of the problems.