Various methods don't call call __finalize__

[TomAugspurger]

Improve coverage of NDFrame.__finalize__

Pandas uses NDFrame.__finalize__ to propagate metadata from one NDFrame to
another. This ensures that things like self.attrs and self.flags are not
lost. In general we would like that any operation that accepts one or more
NDFrames and returns an NDFrame should propagate metadata by calling
__finalize__.

The test file at
https://github.com/pandas-dev/pandas/blob/master/pandas/tests/generic/test_finalize.py
attempts to be an exhaustive suite of tests for all these cases. However there
are many tests currently xfailing, and there are likely many APIs not covered.

This is a meta-issue to improve the use of __finalize__. Here's a hopefully
accurate list of methods that don't currently call finalize.

Some general comments around finalize

1. We don't have a good sense for what should happen to attrs when there are
   multiple NDFrames involved with differing attrs (e.g. in concat). The safest
   approach is to probably drop the attrs when they don't match, but this will
   need some thought.
2. We need to be mindful of performance. __finalize__ can be somewhat expensive
   so we'd like to call it exactly once per user-facing method. This can be tricky
   for things like DataFrame.apply which is sometimes used internally. We may need
   to refactor some methods to have a user-facing DataFrame.apply that calls an internal
   DataFrame._apply. The internal method would not call __finalize__, just the
   user-facing DataFrame.apply would.

If you're interested in working on this please post a comment indicating which method
you're working on. Un-xfail the test, then update the method to pass the test. Some of these
will be much more difficult to work on than others (e.g. groupby is going to be difficult). If you're
unsure whether a particular method is likely to be difficult, ask first.

• DataFrame.__getitem__ with a scalar
• DataFrame.eval with engine="numexpr"
• DataFrame.duplicated
• DataFrame.add, mul, etc. (at least for most things; some work to do on conflicts / overlapping attrs in binops)
• DataFrame.combine, DataFrame.combine_first
• DataFrame.update
• DataFrame.pivot, pivot_table
• DataFrame.stack
• DataFrame.unstack
• DataFrame.explode BUG: added finalize to explode, GH28283 #46629
• DataFrame.melt BUG/TST/DOC: added finalize to melt, GH28283 #46648
• DataFrame.diff
• DataFrame.applymap
• DataFrame.append
• DataFrame.merge
• DataFrame.cov
• DataFrame.corrwith
• DataFrame.count
• DataFrame.nunique
• DataFrame.idxmax, idxmin
• DataFrame.mode
• DataFrame.quantile (scalar and list of quantiles)
• DataFrame.isin
• DataFrame.pop
• DataFrame.squeeze
• Series.abs
• DataFrame.get
• DataFrame.round
• DataFrame.convert_dtypes
• DataFrame.pct_change
• DataFrame.transform
• DataFrame.apply
• DataFrame.any, sum, std, mean, etdc.
• Series.str. operations returning a Series / DataFrame
• Series.dt. operations returning a Series / DataFrame
• Series.cat. operations returning a Series / DataFrame
• All groupby operations (at least some work)
• .iloc / .loc Add missing __finalize__ calls in indexers/iterators #46101

[TomAugspurger]

How __finalize__ works with methods like concat requires a bit of discussion. How do we reconcile metadata from multiple sources?

In #27108, I'm using _metadata to propagate whether the NDFrame allows duplicate labels. In this situation, my ideal reconciliation function would be

def reconcile_concat(others: List[DataFrame]) -> bool:
    """
    Allow duplicates only if all the inputs allowed them.

    If any disallow them, we disallow them.
    """
    return all(x.allows_duplicates for x in others)

However, that reconciliation strategy isn't valid / proper for arbitrary metadata. Which I think argues for some kind of dispatch system for reconciling metadata, where the attribute gets to determine how things are handled.

allows_duplicate_meta = PandasMetadata("allows_duplicates")  # the attribute name

@allows_duplicate_meta.register(pd.concat)  # the method
def reconcile_concat():
    ...

Then we always pass method to NDFrame.__finalize__, which we'll use to look up the function for how to reconcile things. A default reconciliation can be provided.

cc @jbrockmendel, since I think you looked into metadata propagation in another issue.

[jbrockmendel]

IIRC I was looking at _metadata to try to implement units (this predated EAs). One of the biggest problems I had was that metadata on a Series didn't behave well when that Series is inserted into a DataFrame.

Do we have an idea of how often _metadata is used in the wild? i.e. could we deprecate it and make an EA-based implementation?

[TomAugspurger]

It’s essentially undocumented, so I’m OK with being aggressive here.

What would an EA-based implementation look like? For something like units, metadata may not be appropriate. I think an EA dtype makes more sense.

I’ll add this to the agenda for next weeks call.

[jbrockmendel]

What would an EA-based implementation look like?

It's a bit ambiguous what this question is referring to, but big picture something like _metadata but with dispatch logic could be done with something like (for this example I'm thinking of units in physics where (4 meters) / (2 seconds) == 2 m/s):

class MyDtype(ExtensionDtype):
    def __mul__(self, other):
        other = getattr(other, "dtype", other)
        return some_new_dtype


class MyEA(ExtensionArray):
     def __mul__(self, other):
         result = self._data * other
         dtype = self.dtype * other
         return type(self)(result, dtype)

[TomAugspurger]

Right. Does the current EA interface suffice for that use case, or are there additional hooks needed?

[TomAugspurger]

Not a blocker for 1.0.

[TomAugspurger]

Do people think that accessor methods like .str and .dt should call finalize? IMO, yes they should.