Treat units info as nu, make nu a list rather than single function #17
Conversation
I'm interpreting that as each artist might need to do separate dunitization depending on what data is being passed in, but that all the conversions have to be consistent such that for multiple artists on one axes:
xref: I think @jklymak was trying to do some of this w/ matplotlib/matplotlib#9776 ETA: also this consistency probably needs to be true at the figure level - like apple shouldn't be mapped to
Um for what it's worth, I kinda thought this was the plan. |
|
The reason that unit conversion belongs the to the Axis (in the Axes) is that there needs to be the matching transform on the tick labels (in the current system we have inverse functions and store the axis limits post-conversion so that the transform stack all "just works", but I think it should be possible to make the whole thing work with only forward functions, but that is a side point). If we are going to put a tick on the axes and label it Another interesting idea to play with is to push on how little the
Part of your job is to sort out the best path on this ;) |
data_prototype/wrappers.py
Outdated
| self._cache[cache_key] = data | ||
| return data | ||
|
|
||
| def __init__(self, data, nus, **kwargs): | ||
| def __init__(self, data, nus, xunits: List[str] = [], yunits: List[str] = [], **kwargs): |
There was a problem hiding this comment.
| def __init__(self, data, nus, xunits: List[str] = [], yunits: List[str] = [], **kwargs): | |
| def __init__(self, data, nus, xunits: Tuple[str] = (,), yunits: Tuple[str] = (,), **kwargs): |
|
My logic for sticking taping 'query' and 'transform' together is so that the caching logic could be implemented in one place [1]. Maybe the right way to change the signature is to (modulo defaults to make them optional) or maybe def _query_and_transform(self, renderer, *nus, invalidate_cache=False):
...where we can take as many as we want and up to the artist sub-class to order them correctly. I can also see a case for def _query_and_transform(self, renderer, nus: Dict[str, List], *, invalidate_cache=False):
...Thus we can stuff the linearization / lookup logic still all in one place and we have an outside control that the [1] There are 2 hard problems in computer science:
|
|
OKay, rebased... I think I got all of the functionality of #15 and this PR... All of the examples seem to work, though I would like to make one with more unit behavior. I also think some solution for ordering the units conversion within the |
This is mostly a proof of concept/concrete implementation that can be discussed for the idea of allowing
nufunctions to actually be lists of functions applied successively.As part of this, the treatment of units has been moved to be in the list of
nufunctions, which allows transformations to happen either pre- or post- unit conversion, based on the order in the list.@tacaswell has stated "nu is a property of the artist, the unit convesion is a property of the host Axes", indicating that perhaps this is not the "correct" way to to treat unit conversions.
I do wish to challenge this thought at least a little bit: the actual call to convert units has a signature that is compatible with
nu(although admittedly it is a bound method rather than a pure function).I further wonder if the key to resolving unit inconsistencies is to handle the units separate from at least some of the existing units machinery and coax the existing machinery to work with the new system rather than the other way around. (Note, that is not to say I want users to have to change their code, but rather just that we don't tie ourselves down too early.)
Now... this implementation was pretty hastily put together and none of our currently implemented examples actually use units yet, so it's not even particularly well tested.
Additionally, the implementation conflicts with changes to
nuproposed in #15.