Altair DataFrame class

[jonmmease]

In #3081, we are integrating VegaFusion to make it possible to extract the transformed data from an Altair Chart object. As discussed in #3081 (comment), it's even going to be possible to extract the transformed data from a chart without any marks configured. e.g:

import pandas as pd
chart = alt.Chart(
    pd.DataFrame({"a": [1, 2, 3], "b": ["A", "BB", "CCC"]})
)
chart.transform_filter("datum.a > 1")._transformed_data()

	a	b
0	2	BB
1	3	CCC

In this case, the Chart object is actually being used more like a lazy DataFrame than a chart. What if we added an alt.DataFrame class that includes a subset of the alt.Chart methods. In particular:

• The .transform_* methods, which would return a new alt.DataFrame. And maybe we even drop the transform_* prefix.
• The .mark_* methods, which would return a new alt.Chart.

VegaFusion doesn't do this efficiently yet, but I'd also picture supporting a .dtypes property that would return the output pandas data types for the alt.DataFrame. We could even use these output dtypes for encoding type inference (the way we currently only do for pandas DataFrames).

Alternative: maybe this functionality could be combined with the existing alt.Data sub classes, so that you could do things like:

alt.UrlData("https://path/to/file.csv").filter("datum.a > 1").transformed_data()
alt.UrlData("https://path/to/file.csv").filter("datum.a > 1").mark_point().encode(...)

---

Please follow these steps to make it more efficient to respond to your feature request.

• Describe the feature's goal, motivating use cases, and its expected behavior.

[binste]

Exciting idea! No clear opinion yet, just some first thoughts. I'm not sure how much we'd want to push this in the direction of a data processing library although with VegaFusion we're almost there and could support different backends similar to Ibis. It could water down the purpose of Altair as a visualization library. Would we then also want to support that intermediate results can be viewed without recalculation of everything as you would expect from a data processing library?

first_df = alt.DataFrame.transform_filter().transform_pivot()....transformed_data()
first_df.head()

first_df.transform_impute().mark_bar()

Right now, this seems too far for me but as I'm typing it I realise that the syntax you propose without intermediate results could be convenient and feel more natural then using alt.Chart for this purpose... On the other hand, if the end goal is a chart I don't think it's bad to start out with alt.Chart in the first place. alt.DataFrame would create a second starting point to create a chart and I like this line from the Zen of Python: There should be one-- and preferably only one --obvious way to do it.

[jonmmease]

Thanks for those thoughts @binste. Yeah, in the near/medium term I think having people use alt.Chart is totally fine. I wanted to bring this up as a thought exercise as much as anything. I had a kind of aha moment when I realized how much similarity there could be between a markless Altair chart and a lazy DataFrame library, and wanted to share.

[binste]

Definitely! I think it's great to explore this further, as a mental construct to help spark ideas or even as an actual feature.