Comments (7)
I may be missing something, but isn't the idea of an alias that is should return the object that it aliases? Now, it is not so clear which is the original and alias here and maybe they are mixed-up? But the thing that an alias returns a different name than the alias name is expected?
from matplotlib.
It's a bit more involved than just changing the name attribute. There is currently only one underlying Colorbar
instance for both. I see two possible resolutions:
- Create explicit copies for the aliases. In this case we'd not really be aliasing anymore but just have two separate colormaps that happen to have the same data values.
- Make the aliasing an explicit concept of
ColormapRegistry
.
Not sure which approach is better. The first is less complex, but we loose from-code accessible information on aliases (not that we have used that before). So slight tendency to go with the first. We can always build explicit aliases in later if we need to.
from matplotlib.
My knee-jerk reaction was "can we just keep living with this", but looking into it a bit, if colormaps are added through ColorMapRegitry.register
then we mutate the passed colormap to match the name we registered it as! I think the grays/grey miss-match exists because we pass the dictionary in rather than registering them one-by-one.
The __eq__
check on ColorMaps
only looks at the values of the LUT (and if it is attached to a colarbar with extends which is odd but did not track down why) and ignores the name.
On __getitem__
we already return a copy so making a copy for the aliases is not a huge conceptual step and the users can't tell if we have one instance we are returning copies of two identical instances we are returning copies of.
This also suggests that rather than fixing the name on the way in, we should be fixing the name on the way out (as we have already paid to make a copy).
from matplotlib.
This issue inspired me to do #28115
from matplotlib.
My knee-jerk reaction was "can we just keep living with this"
That would be still an option.
On
__getitem__
we already return a copy
This was added to prevent users from manipulating the builtin colormaps, e.g. via set_over()
. There is the idea to make colormaps immutable eventually. While immuatbility is the better option, I'm unsure whether we want to enforce the associated API change. But if we do, the copy could go away.
This also suggests that rather than fixing the name on the way in, we should be fixing the name on the way out (as we have already paid to make a copy).
I don't follow that argument. The existing copy only means: We can fix the name of the way out without additional cost. I still think it's not the right way, because we have a sketchy internal state. self._cmaps['grey'].name == "gray"
should not happen. Either we invest in the handful of additional copies on the way in (Option 1 from above). Or, we do not have _cmaps['grey']
and and let __getitem__
handle alias resolution. But this also means we have to specially handle aliases in keys, which brings us to the explicit alias concept (Option 2 from above).
from matplotlib.
I may be missing something, but isn't the idea of an alias that is should return the object that it aliases?
That depends on the interpertation. First and foremost, we want to give users the convenience that 'grey' and 'gray' are equally possible. AFAIK, we have not publically defined the mechanism how that is implemented. If we publically say "One is canonical and the other is just an alias for accessing plt.colormaps[name]
", then the current behavior is ok. The alternative is to just have two identical colormaps with different names.
I think the second approach is more pragmatic, because plt.colormaps[name] != name
is surprising and can only be understood if you know that we have aliases.
Note also that since we currently do copies on __getitem__
, you never get the object. You'll always get new objects, which are equal but not identical.
from matplotlib.
Thanks @timhoffm. Agree completely, immutability, readonly, is Good.
(What surprised me: I was plotting colormaps with ΔE color diffs, about like
for name, v in mpl.colormaps.items():
if re.match( "Gr", name ):
plot ... v.name ... ) # Greys twice ❓
from matplotlib.
Related Issues (20)
- [Bug]: PolygonSelector should hide itself when zoom/pan is active HOT 6
- [Bug]: Removing tools from the toolmanager that are not on the toolbar triggers an exception
- [TST] Upcoming dependency test failures
- [Doc]: `get_figure` may return a `SubFigure` HOT 7
- [ENH]: Make the font family "Computer Modern" more accessible HOT 1
- [Bug]: Log scaled barplots in PDF result in infinite rectangles HOT 3
- [Bug]: `Path.cleaned()` always returns a closed path HOT 8
- [ENH]: Drop STOP codes? HOT 1
- [Bug]: mathtext should distinguish between unary and binary minus HOT 4
- [MNT]: Essential build requirements not included in dev-requirements
- [Doc]: ConnectionError when using intersphinx: https://matplotlib.org/stable/objects.inv HOT 2
- [MNT]: Colormaps odd behavior (1 != 1.0) HOT 13
- [MNT]: Misleading function name `Poly3DCollection.get_vector()` HOT 1
- [Bug]: Interactive Mode Image Visualization HOT 1
- [Bug]: Qt test_ipython fails on older ipython HOT 2
- [TST] Upcoming dependency test failures HOT 1
- [Doc]: quiver ‘scale_units’ description is not very not clear HOT 1
- [Bug]: typehint missing for matplotlib Axes HOT 1
- [ENH]: Faking a text's metrics to fix its alignment HOT 1
- [Bug]: Matplotlib not work with MiKTeX. HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from matplotlib.