proposal: support levels for the duplicated APIs in ibis

[datapythonista]

There are a significant amount of things in Ibis that can be done in more than one way. This is particularly true for the Impala backend. For example:

expr.compile() or ibis.client.compile(expr)

ibis.client.drop_table('table_name') or con.table('table_name').drop()

I'm planning to remove the aliases, and just leave the expr.compile() or table.drop() syntax.

Please let me know if anyone has got comments.

[cpcloud]

Yep, there are a fair number of duplicate APIs.

I propose the following categorization:

1. LTS Aliases

Duplicated APIs that are deliberately supported and mentioned in the docs and internally.

Examples

• __getitem__/__getattr__ overloads

2. "Docprecated": Preferred but never warned-on or removed

These APIs have preferred versions which are used everywhere internally and in documentation, while their alternatives are not mentioned anywhere or used internally except possibly in tests. They are supported.

Examples

• order_by/sort_by: prefer order_by (adding in feat(api): add order_by alias for sort_by #3188), sort_by continues to live on forever
• select/projection: prefer select, projection will never go away but it will not be mentioned in documentation or used internally.

3. Deprecated: Slated for removal in a major release

Various APIs are duplicative (by more than a factor of 2 or 3) and cause unnecessary confusion.

These APIs will cease to be available in a following major release.

Examples

• materialize
• set_column/set_columns
• get_column/get_columns

[cpcloud]

The goal here is to have the community discuss the specific tiers of APIs and what should be in each bin.

[cpcloud]

This is stale, and didn't garner much interest.