Awkward array design issues

[HDembinski]

Awkward arrays have a minimal amount of methods, instead a lot of functionality that one would expect to be provided by attributes and methods is provided by free functions, e.g. ak.fields. I am personally also an advocate of functional programming, but I believe that this design harms the library, since

1. Python users do not expect to use functional programming. Python is multi-paradigm, but the object orientation is strong, with everything being an object. The awkward design fundamentally goes against what is generally considered Pythonic.
2. The argument given in the docs in favor of using free functions is to keep the attribute name space of the Array object free, since record-array-like arrays expose their fields as attributes. This root cause is a poor design choice, since it does not always work anyway, the record could be named so that is does not map to a valid attribute name. It also creates two ways of accessing the field instead of offering the One Way To Do It as demanded by the Zen of Python. It is not worth sacrificing all that to save typing two quotes and a bracket.

A Pythonic design would make record-array like awkward arrays behave like dicts, so that I can access the fields with .keys() and generally use the dict interface.

As it is designed now, awkward arrays do not feel Pythonic at all, which means that someone used to Python has to look everything up in the docs instead of being able to rely on common patterns that are established in the Python world.

[agoose77]

I only have five minutes to throw in my two-cents here; I agree that some of the design decisions made by Awkward are "non-Pythonic", but I think they are necessary. Note that this is a third-party perspective rather than a core maintainer's.

In the domain that the Scientific Python stack occupy, NumPy+Pandas are effectively DSLs. As such, NumPy is also not incredibly Pythonic by your metric; the array interface doesn't require arrays to implement methods, it only describes compatability with the high level APIs.

One of the core features of Awkward is making structure low cost (both physically, and mentally). That is why fields move through indices in the __getitem__ operation. The intended consequence (I believe) is that users can add structure to better data e.g. here

With all of this structure, there are really three options:

1. Only support __getitem__
2. Support both __getitem__ and __getattribute__
3. Create a proxy attribute e.g. array._.x

If you require the . namespace for Awkward methods (1), something like events.kaons.id becomes events['kaons']['id']. Personally, I find that harder to read (and there is a reason that people write object wrappers over structured JSON).

The proxy method could work, but it feels a bit awkward, and I could see it going wrong events._.kaons._.id.

I don't think there is anything wrong with a library deviating from Pythonic standard, because a lot of what the ecosystem does is non-Pythonic; Numba requires you to write low level loops, and in conventional NumPy code, classes are frequently inapplicable to data analyses where the class effectively changes with every operation. That's why Awkward behaviours are interesting - they provide a much more lightweight solution to OO programming in the space. In fact, you could go as far as to say that the behaviour paradigm is true OO - instead of every type having a suite of (NumPy) methods that originate from a data member (e.g. a class with a list attribute exposing all the list methods), Awkward only implements the interface that the behaviour designer intends.