Repository navigation
Specifying dictionary argument with dict() or braces matters in set_bbox #1934
Description
In matplotlib home page, there is a link to a tutorial by Nicolas Rougier. In the section of the tutorial entitled "Devil is in the details", the script:
http://www.loria.fr/~rougier/teaching/matplotlib/scripts/exercice_10.py
produces the figure displayed on the web page. Line 48 of the script is:
label.set_bbox(dict(facecolor='white', edgecolor='None', alpha=0.65 ))
If we replace this line by:
label.set_bbox({"facecolor": "white", "edgecolor": "None","alpha":0.65})
then the edgecolor request is not taken into account. The two statements above should be equivalent. The author of the tutorial, Nicolas Rougier, is surprised too. People on stackoverflow think it is a matplotlib bug:
Activity
WeatherGod commentedon Apr 23, 2013
From the bit of digging I have done on this, there doesn't seem to be
anything in the text.py codebase that processes a property dictionary in
such a way that order would effect it. That would mean that this problem
is merely the tip of an iceberg. One way to really test this hypothesis of
order-dependent processing is to utilize OrderedDictionaries and try out
every possible combination of those entries and see which ones work and
which ones don't. Then, I would try to see if the problem could be
reproduced with a simple patch object,
cimarronm commentedon Apr 23, 2013
The problem is not with the way you instantiate a dictionary but the order. If I run the test program, sometimes I see the edge and sometimes not depending on the random ordering of the dictionary.
The issue arrises when
alphacomes afteredgecolorand the fact that there is no special edgecolor for "none". Instead when one sets edgecolor to "none" it gets transfered to a RGBA tuple of (0,0,0,0). Then when alpha is set it makes it (0,0,0,0.65) in the example (i.e. black with an alpha of 0.65) which is why the edge shows up.I believe the solution is to actually allow colors of
Nonebut code would have to change to accept and interpret a None value in addition to the RGBA tuple, i.e. a color of none and black with zero alpha are indeed different.pelson commentedon May 13, 2013
@cimarronm - is this now fixed?
lguez commentedon May 13, 2013
Thank you. Am I supposed to close this issue myself? (I do not have the update with the correction myself.)
cimarronm commentedon May 14, 2013
@pelson: I tested it and it is fixed thanks to the good work from @Westacular
pelson commentedon May 15, 2013
Great. thanks for the update.