-
Notifications
You must be signed in to change notification settings - Fork 231
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
Comments
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 |
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. |
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: |
Right now if one wants to use
sobol
, we need to do:But we also have:
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:(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.The text was updated successfully, but these errors were encountered: