There were a lot of merge conflicts because of the two different approaches. A few meetings ago, I think we said we wanted to use the encoding conversion part from
palnabarun/encodings and the data extraction/chart reading part from
kdorr/convert-numeric, which is what I tried to do in the merge.
test_utils.py, since the way that
kdorr/convert-temporal and ‘kdorr/convert-numeric` extract the data from the chart didn’t require reading any urls, the functions in _utils.py weren’t being used after the merge.
_utils.pyhad code to handle cases where the user gave an online dataset as a source.
git cleanto remove build artifacts
[ ] axis
axis.tickOpacity Not Supported by altair
I’ve had an idea to create a class that would allow the data/metadata from the altair chart to be parsed and stored in an object. This seems a little cleaner to me than our current implementation, which is to re-parse a portion of the chart for each channel in each step of the conversion.
I’m thinking it would look something like this: https://gist.github.com/kdorr/bff03aee0593102c46fa4568568b0076
It would simplify convert_axis() (https://github.com/matplotlib/mpl-altair/blob/master/mplaltair/_axis.py#L222), _convert() (https://github.com/matplotlib/mpl-altair/blob/master/mplaltair/_convert.py#L121), and current/future implementations of different chart types.
However, it’s currently possible to add other plot types without this and lot of the current codebase would need to be tweaked to work with the change (namely _axis.py and _convert.py). It would probably take me .5-1.5 days to implement it.
Could I get feedback on this? Is it something that would be useful to work on? If so, with the limited time left this summer, is it worth pursuing right now?
SimpleNamespace( https://docs.python.org/3/library/types.html#types.SimpleNamespace) if the goal is to just stash pre-derived values from the altair input