Future of cpp interface

[henryiii]

@HDembinski suggested exposing the C++ wrapper objects as the cpp backend. That has possible pros and cons:

Cons:

• Directly exposes more of the C++ backend, which needs to be recompiled to be changed
• Requires "nice" API, such as named/optional arguments, in the PyBind layer. If something like FASTCALL is supported in the future, it may limit our option to use it.
• Readthedocs will not pick up the C++ docstrings (not that the cpp module is all that well documented now)
• Improvements to the Python layer (like Pandas (and other array package) improved compatibility #380) will not be available to cpp, like data conversions, indexing, and such.
• Things hidden in Python, like the fact that each set of axis options is a different axis class, and there is a histogram class per storage, will not be hidden in cpp anymore
• You won't be able to cast back and forth between Python and cpp objects (but more on that later)
• We can't protect against arbitrary Python objects being passed in, so some errors and even segfaults might not be avoidable (passing in an object with a broken repr segfaults PyBind11, for example, IIRC)

Pros:

• Simpler to maintain - learning the cpp interface will also be the bound interface (though not all workarounds for Python magically go away)
• Might simplify the casting structure. It is critical that all objects be subclassable for use by dependent projects (such as Hist), but the mapping process might get easier, as the common point could be the internal cpp object. We need to keep good tests for this behavior if we remove the cpp family.
• Less repetitive, more DRY
• Might get rid of the bindings being _core and become a public cpp (basically both a pro and con - simpler but now public instead of private)

I think it boils down to the cpp interface - if is okay to be made less user friendly, dropping the extra layering should make maintenance simpler in the long run. @HDembinski, you are probably the heaviest user of cpp. I think it's very low priority - user-facing items like #380 are much more important. Maybe we should add a warning when cpp is imported that it is not considered a stable API?

[HDembinski]

I also gave this more thought. We chose the current complex way of doing things because it is not straight forward in Python to hide public methods in a base class from users of a derived class. In C++ that is supported, but Python was not designed to make this easy. There are ways to do it, but those are not pretty.

My primary goal with this is to make boost-histogram simpler. We have limited resources and easy maintenance and extensibility of the project is very important. For us, but also for new contributors.

So I weighed the cost of having the cpp interface layer against all that and come to the conclusion that I rather drop that layer, including the tests. Whoever is using Boost-Histogram has to learn the Python interface. We should, of course, continue to document the general rules that we applied when we designed the Python, but that should just be a section in the docs.

Frequent switches from C++ to Python, as I originally anticipated, seem much less likely now. uproot and numba have removed the need to write C++ to read and process ROOT files. So let's remove the alternative cpp interface and remove all the clutter which we had to introduce to support it.