polars

polars copied to clipboard

Having describe_plan and describe_optimized_plan is confusing for newcomers and verbose. Propose to deprecate these and replace them with something like:

def plan(
        optimized:bool = True,
        type_coercion: bool = True,
        predicate_pushdown: bool = True,
        projection_pushdown: bool = True,
        simplify_expression: bool = True,
        slice_pushdown: bool = True
)

If combining the two functions I'd keep the name describe_plan (as it does indeed return a description of the plan, and it's what people are used to), adding the params as suggested (though don't need 'optimized'). Just plan is a bit ambiguous.

If combining the two functions I'd keep the name describe_plan (as it does indeed return a description of the plan, and it's what people are used to), adding the params as suggested (though don't need 'optimized'). Just plan is a bit ambiguous.

Does it not need the optimized param to allow the non-optimized plan to be returned?

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 are preferred over more arguments. Take for instance the is_sorted methods in rusts iterators: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.is_sorted.

Having more explicit function calls make code more readable IMO. You can create the same readability by only allowing keyword arguments/ which I am also in favor of. But either way, it will be a bit more verbose.

Which I think is good. As I like readable code.

Does it not need the optimized param to allow the non-optimized plan to be returned?

No; I believe it would just need all the other params set to False, as they are the optimizations.

Having describe_plan and describe_optimized_plan is confusing 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 the plan"

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 the plan"

It does have merit. It is the query plan 'as is'. Comparing the two shows which optimizations polars does. We often have to compare them both.

This method is now called explain and it has a parameter optimized=True/False defaulting to True.

I believe this issue has been adequately addressed. If not, please open a new issue.