-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink decision to expose the public interface in namespaces #1900
Comments
Turns out that from deltalake import write_deltalake So the only issue we need to think about is if we want to keep this: dt.optimize.z_order(["some_col"]) Or if we'd like to switch it to something like this: dt.z_order(["some_col"]) |
I think we should keep these namespaces such as optimize, and in the future the alter namespace. It makes it easy for users to find a set of interactions on the table clustered together. Example: |
@ion-elgreco - Yea, that sounds fine with me, especially because Let's make sure to keep all the verb conjugations of any new namespaces consistent with the I do think we should have at least three methods inside of a namespace to justify the separate namespace. Right now, |
@MrPowers yeah sounds good! |
@MrPowers shall we close this one? |
@ion-elgreco - yep, we can close this one, thank you!! |
Description
The public interface is currently exposed in different namespaces, which can make imports a little tricky. Users currently have two options when writing code. They can do something like this:
Or they can do something like this:
We should consider following the pandas style and exposing the entire public API in the
deltalake
namespace. Here's some idiomatic pandas code:I think this end-user interface could be nicer:
This would also allow for a nice single-line import if users prefer this style:
The text was updated successfully, but these errors were encountered: