Add a "path" to ak.with_field and array["outer", "inner", "new_field"] = new_field syntax to ak.Array/Record.

I got quite confused when i (wrongly) assumed that i can assign fields to arrays

>>> import numpy as np
>>> offsets = np.random.randint(0, 10, size=5)
>>> x = ak.zip({k : [np.random(off) for off in offsets] for k in ["a", "b"]})
>>> d = 2 * x.a
>>> x.d = d # wrongly assumed this is equivalent to x["d"] = d
>>> x = x[x.a > 0.9] # ups, now x.d is gone

Would it make sense/be possible to implement __setattr__ to do the same thing as __setitem__? Or if that introduces other problems, warn users they should not do that?

[jpivarski]

I’ve been on the fence about this because all the other attributes that attach to an ak.Array have to be attached carefully (by directly accessing the __dict__ or calling the superclass’s __getattr__ or __getattribute__ or something; I’d have to look it up and experiment).

I’ve asked this question when presenting Awkward, whether the argument for x.d = d is strong enough to warrant the potential for issues like, “Oops, now we can’t add new features to ak.Array,” or “Oops, now exceptions that happen inside the assignment (like d doesn’t broadcast to x) are hidden, or a wrong error message is raised.” Something very much like that happened with __getattr__ until we found a way to navigate around all the consequences. In that case, the argument for __getattr__ access was strong enough to do it.

Also something to consider: Pandas used to have this ability and now they’ve deprecated it and raise warnings if users attempt it.

>>> import pandas as pd
>>> df = pd.DataFrame({"x": [1, 2, 3], "y": [1.1, 2.2, 3.3]})
>>> df
   x    y
0  1  1.1
1  2  2.2
2  3  3.3
>>> df.z = [100, 200, 300]
__main__:1: UserWarning: Pandas doesn't allow columns to be created via a new attribute name - see https://pandas.pydata.org/pandas-docs/stable/indexing.html#attribute-access
>>> df
   x    y
0  1  1.1
1  2  2.2
2  3  3.3
>>> df["z"] = [100, 200, 300]
>>> df
   x    y    z
0  1  1.1  100
1  2  2.2  200
2  3  3.3  300

(But they do allow df.x is df["x"].)

I don’t know if they hit some bad design issues or something. Maybe a warning is in order? I normally don’t like warnings because they tend to not do what they’re supposed to do—they often get buried in a script with no one watching to see them, or when they are observed, they pertain to something so many steps away from what the user is doing that the warning doesn’t make sense. But since Pandas does it, maybe we should too…

I think I’m going to label this as a “discussion” because what we have to think about goes well beyond the simple matter of implementing __setattr__.

[jpivarski]

I changed the title to be clear about what this feature request is requesting. I’m also going to add “good first issue” because this can be implemented with only a little Python meddling, not deep changes to the C++.