Swimming upstream
This week I’m struggling with the joys? of upstream changes and trying to sort out where support should happen and where it realistically will happen. The story starts with a somewhat major change between Python 2 and Python 3, namely that given a dictionary d = {'a':1, 'b':2, 'c':3}
, d.keys()
, d.values()
, and d.items()
now return dictview objects. Now deep down the matplotlib stack, data almost always gets converted into a numpy array…and that’d be fine ‘cept this is what happens when you try to turn view into an array:
In [6]: np.asarray(d.keys())
Out[6]: array(dict_keys(['c', 'a', 'b']), dtype=object)
In [7]: np.array(d.keys())
Out[7]: array(dict_keys(['c', 'a', 'b']), dtype=object)
So that thing it returns? array(dict_keys(['c', 'a', 'b']), dtype=object)
isn’t indexible or iterable and is in fact a 0-d array. This is why to work with dicts in python3 in matplotlib, the current protocal is:
plt.bar(list(d.keys()), list(d.values()))
which I feel is rather unweildy. And so I proposed to my mentors that I write something that’ll support dicts natively and in theory be extensible to other non-numpy friendly datatypes…Step one was figureing out what datatype would go in an isinstance
check. Here I got super confused ‘cause type(data.keys())
returns dict_keys
and the documentation says dictview
and neither of those work in isinstance
. Was frustrated and so popped into #python-dev (‘cause I thought it was a docs/api inconsistency) where I was told that dictview
and the rest won’t work ‘cause of a deliberate choice to not make them builtins and the type to use for introspection is collections.abc.MappingView
. The docs confusion is now issue #27544 with a developer provided patch that’s awaiting review.
But with that resolved, I wrote some code (pull request #6787) which is a decorator that inspects arguments and converts MappingView objects to lists. It can almost definitely be refined and optimized and the like, but right now the discussion is at a more basic “wait, where should support for this go?” Is it a well numpy arrays so patch in numpy (where it’s open issue #5718) deal, or should matplotlib potentially support types that aren’t numpy convertable, even if matplotlib supports those types by making them convertible. It speaks to core design philosophy, and so can be kinda thorny.
I feel like this is the moment where it really feels like I’m working on a big project with multiple people with very strong opinions; up ‘til now my mentors had mostly shielded me from that. :/
Image Source: xkcd #754