Ritchie Vink

Hmm... Object support is still not optimal in polars. Could you tell me a bit about what you want to do? Big chance we can do it without objects.

> Having describe_plan and describe_optimized_plan is confusing I don't agree this is confusing. It does exactly what is says. The naming is a bit similar to rust where different functions...

> I'm giving a workshop this week and find I'm having to say "ok, ignore this describe_plan if you want to know what's going to happen because it's not actually...

I will close this as this is a setup problem.

Polars' categorical type only maps to string categories. What do you think we should have done here? Should we cast to integers? The error seems quite informative to me.

We do not support grouping by a column of type list. I think we should improve the error message on that.

I think a `ComputeError` would be most consistent. For structs we could temporarily unnest -> do the groupby -> and nest again.

That is definitely something that is in scope. But i don't really see how we must provide the types. Do we need the `DataFrame` object to accept types? Something that...

But they are a runtime type check I assume? Or they only exist in spark (not pyspark). If we would have that at compile time we would have a combinatorial...

For reference this is what we have implemented: https://stats.stackexchange.com/a/111912/147321