uproot design issues

[HDembinski]

uproot's design does not follow the One Way To Do It principle from the Zen of Python. The interface contains a lot of redundancy, instead of offering a minimal design. The cost of adding redundancy to the interface is longer docs, more required effort to learn the library from the user, and more unit tests to test all that interface. It adds cost both for the developer and the user.

The issues permeate the whole library, so I will use only an example for illustration. I pick uproot.TTree.iterate.

• The keyword filter_name is redundant. The reason that both the keywords expressions and filter_name exist is probably because the author realized that one could have branch names that look like filter expressions, so that expressions cannot always be unambiguously interpreted as filters. The best conclusion from this correct analysis is to not support filter_name at all. It is easy in Python to grab all the branch names from the tree and filter them using powerful and concise Python expressions, like list comprehensions. There is no need to introduce a string-based DSL shortcut for this.
• Likewise, filter_typename, filter_branch are superfluous. cut as well, as the docs say, cut is not faster than doing the filtering by hand in numpy, therefore is no reason to add this functionality.

It is important to resist feature requests for such trivial functionality. Users do not always know what they really need. It is analog to the saying, "Give a man a fish and he is fed for a day. Show a man how to fish and he is fed for a life-time". Whenever you build a DSL or a shortcut that solves a problem by saving a few keystrokes, you give the user a fish. It will make that user who requested it happy, but that user would have been served much better by pointing out how the problem he wants to solve can be solved in standard Python without adding extra shortcuts to the library. The shortcut only works for this library. The general Python pattern on how to solve the problem works everywhere. There are certainly exceptions to this rule for code that one has to type interactively a lot, but uproot.TTree.iterate is not something you type every cell of a notebook.

Python's success is to a great deal build on being a well-designed language with a (mostly) well-designed standard library, which in turn is largely based on some core developers caring deeply about minimal sufficient designs that are used consistently everywhere. It requires active effort to fight interface entropy and redundancy and also an understanding why minimal sufficient interfaces are so powerful in the long-run.