Mutating Annotation data / JamsFrames

Before making sawdust and creating a PR, I wanted to discuss the (my?) problem, and how I plan to address it. In the following, I use ann to refer to an instance of an Annotation, and obs to refer to an instance of Observation.

The situation I’m facing:

• I would like to transform the observations in an annotation; either in-place or returning a copy would do.
• AFAICT, the best (only?) way to change the data in an annotation is to (1) get a copy of the JamsFrame, modify the object separately, and reassign as ann.data.from_dataframe.
• Modifying the contents of a pandas DataFrame (view vs copy) is perhaps the most frustrating / non-intuitive facets of the library.

A few observations:

• We don’t actually have an observation iterator (?), e.g. there’s no way to cleanly say [fx(obs) for obs in ann]
• The data object is persistent and owned by the annotation, which makes mutating it directly seem like an option.
• It’s not obvious to a user that ann.data is a subclassed JamsFrame and not a DataFrame. However, direct reassignment is currently allowed (ann.data = ann.data[:20]), which changes the object type (JamsFrame -> DataFrame) and breaking things later.

My proposal:

1. Either (a) make an Annotation object directly iterable (with an __iter__ & __next__), such that it returns references to Observation objects like above, or (b) add an explicit ann.observations(copy=False) method that allows for one to iterate over the content in an Annotation.
2. Leave the internal (private) data structure of observations as a pure-Python object, i.e. a list.
3. Make data an on-demand view of ann._observations rather than an attribute, achieved by decorating data as a @property. We could also add a setter, which would coerce DataFrame-like objects to be JamsFrames (via from_dataframe), helping to avoid user error.

thoughts?

update: I see now there are two options: update a dataframe and reassign, or step through the iterrows of the JamsFrame and create a new annotation, like in Annotation.trim.

[ejhumphrey]

I’ll be honest, I failed to appreciate the true depth of the situation, and yea, there are some major architectural considerations here. The Right Answer™️ is the one that only extends the current interface (because I agree it is powerful quick for many things).

Like I said, I am unblocked, but will continue mulling this over and look forward to chatting about this in the future (Rochester?).

[bmcfee]

Alright. I’ll close this one out then, but reopen it if something specific to data mutation crops up.