feat: support categorical axes on boost histograms

[lobis]

Closes #672.

The logic for setting the fLabels on the axis is pretty straightforward, however to achieve this we need to serialize THashList which is not currently implemented.

While working on this I found out a problem when serializing TList (which THashList inherits directly from), which is pointed out in #762 and is fixed by #763.

Another issue related to weighted histograms was also found and fixed at #774.

Summary of changes:

• Implement THashList serialization and to_HashList factory method.
• Add tests for THashList writing. Compare serialization (bytes) to TList as they should be the same except for class name.
• The name (fName) of all axes is now xaxis, yaxis or zaxis regardless of user definition, as this field should not be modified by the user since it causes problems on histogram drawing. (The text of the axis is fTitle). Tests have been updated accordingly.
• Add tests for histograms with categorical axes.

[lobis]

At this point serialization appears to work okay but the axis is not being drawn in the histogram (drawn using root). This is probably due to some badly set option. I will compare the uproot generated histogram with one generated with root to see the differences.

import hist
import uproot
import numpy

cat_axis = hist.axis.IntCategory([1, 2, 3], label='Category')
h = hist.Hist(cat_axis)
h.fill(
    numpy.random.randint(1, 4, 1000)
)

with uproot.recreate("test.root") as f:
    f['h'] = h

[jpivarski]

It all looks good and I approve. Thank you very much for the effort you put into this!

One thing now looks odd to me: you've removed the three instances of

    def to_boost(self, metadata=None, axis_metadata=None):
        return super().to_boost(metadata=metadata, axis_metadata=axis_metadata)

which bypass the no_inherit mechanism, which prevents normal inheritance because of the ROOT histogram inheritance tree. So how is TH1D getting a to_boost method?

I can see that it is because these tests pass:

https://github.com/lobis/uproot5/blob/c294f8f5ccd67ff1d75799074e2621736c5abaab/tests/test_0046-histograms-bh-hist.py#L2821-L2842

(I was about to add them, but they were already there.)

[jpivarski]

Nevermind—I think I see it: no_inherit prevents Python classes from being applied to C++ objects in which the C++ class hierarchy has a superclass of that name, but it doesn't do anything to Python inheritance itself (which is good, because that would be confusing).

https://github.com/lobis/uproot5/blob/c294f8f5ccd67ff1d75799074e2621736c5abaab/src/uproot/deserialization.py#L78-L83

Tthe Python inheritance is

graph TB
    A((Histogram))-->B((TH1))
    A-->C((TH2))
    A-->D((TH3))
    A-->H((Profile))
    H-->E((TProfile))
    H-->F((TProfile2D))
    H-->G((TProfile3D))

Loading

and the C++ inheritance is

When we deserialize a TH3F, for instance, we see that it has a C++ superclass named TH3, and we have a registered Python behavior for TH3, so its methods and properties get mixed into the histogram Model class (Model_TH3F_v#). Since TH3 is set to "no_inherit" from TH1, we don't mix our TH1 methods and properties into that object. However, our Python TH3 is a Python subclass of Histogram, so it gets all of the Histogram methods, including to_boost.

So this PR makes complete sense to me. I'll squash-and-merge it.

Thanks again!

[lobis]

I will merge (squash!) once the tests pass.