Skip to content
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

Make functions accessible from the global namespace #582

Open
tupui opened this issue Jul 25, 2023 · 3 comments
Open

Make functions accessible from the global namespace #582

tupui opened this issue Jul 25, 2023 · 3 comments
Labels
clean up/maintenance Changes to clean up code or for maintenance enhancement

Comments

@tupui
Copy link
Member

tupui commented Jul 25, 2023

Right now if one wants to use sobol, we need to do:

from SALib.analyze import sobol

But we also have:

from SALib.sample import sobol

And if we need both, we need to use an alias (as).

I propose that we populate all __all__ from the __init__.py of the various modules. This way we could do:

import SALib

SALib.analyze.sobol(...)
SALib.sample.sobol(...)

(Note: for that to be possible, we would also need to change the API as we have sample everywhere.)

Doing so, we can even also advertise for an alias. I know, some folks advocate for never using aliases. But in this specific case, a natural alias would be sa. Which is the acronym we always use in our field.

import SALib as sa
@tupui tupui added enhancement clean up/maintenance Changes to clean up code or for maintenance labels Jul 25, 2023
@tupui
Copy link
Member Author

tupui commented Jul 25, 2023

This might be a 2.0 event. I've been looking at the whole API and there are a lot of potential for cleaning/improvements.

On the topic of import, there is the obvious change from import SALib to import salib (lowercase is recommended in the PEP and is really the standard).

@ConnectedSystems
Copy link
Member

ConnectedSystems commented Jul 25, 2023

A v2.0 API is something I've been thinking about as well. I have been meaning to sit down and write down a draft spec for discussion. Won't happen anytime soon though.

Regarding the imports, for general use I recommend using the ProblemSpec interface for most people these days, and I think that will be more true for v2.0. The interface also avoids that slightly awkward import use case.

People who are experienced enough with Python can generally work out what to do with the imports, but I agree it's not as clear as it could be.

@tupui
Copy link
Member Author

tupui commented Jul 27, 2023

I see, thanks for the perspectives. Whatever we go for, I think it's important to be clear from a user perspective with what is public, private and how to access things.

I forgot to mention that there is a handy library to do lazy loading:

https://github.com/scientific-python/lazy_loader

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clean up/maintenance Changes to clean up code or for maintenance enhancement
Projects
None yet
Development

No branches or pull requests

2 participants