Idiomatic import for SciPy
Hi everyone, Since SciPy 1.9, we now have a lazy import mechanism which allows us to do `import scipy` and then work on any submodules without waiting time due to the import itself. NumPy and Pandas, just to name these, have set a precedence for an idiomatic way of importing their library. This is arguably an advantage for introspection, debugging, teaching, consistency or even communication purposes. Hence, I would like to propose that we also adopt an idiomatic import style for SciPy. If we would want to move forward with that idea, I would propose to make a brainstorming session with interested people to discuss the topic. This could for instance be a topic for next week’s community call. Cheers, Pamphile
Thanks Pamphile. I just wanted to chime in and note that the introduction of lazy loading has (IMO) been a huge usability improvement. I personally now use `import scipy as sp` in code that I write and libraries that I contribute to like networkx have also adopted this pattern. The main reason that NetworkX has adopted this pattern is to ensure consistency and explicitness in the code base. For example, in networkx we have references to at least 4 different `linalg` packages: `numpy.linalg`, `scipy.linalg`, `scipy.sparse.linalg` and `networkx.linalg`. We now always refer to these explicitly from the top-level package alias, i.e. `np.linalg`, `sp.linalg`, `sp.sparse.linalg` etc. This is of course only one of many possible access patterns, but the introduction of lazy loading made this much more convenient! ~Ross On Tue, May 23, 2023 at 10:40 AM Pamphile Roy <roy.pamphile@gmail.com> wrote:
Hi everyone,
Since SciPy 1.9, we now have a lazy import mechanism which allows us to do `import scipy` and then work on any submodules without waiting time due to the import itself.
NumPy and Pandas, just to name these, have set a precedence for an idiomatic way of importing their library. This is arguably an advantage for introspection, debugging, teaching, consistency or even communication purposes. Hence, I would like to propose that we also adopt an idiomatic import style for SciPy.
If we would want to move forward with that idea, I would propose to make a brainstorming session with interested people to discuss the topic. This could for instance be a topic for next week’s community call.
Cheers, Pamphile
_______________________________________________ SciPy-Dev mailing list -- scipy-dev@python.org To unsubscribe send an email to scipy-dev-leave@python.org https://mail.python.org/mailman3/lists/scipy-dev.python.org/ Member address: rossbar15@gmail.com
On Tue, May 23, 2023 at 7:40 PM Pamphile Roy <roy.pamphile@gmail.com> wrote:
Hi everyone,
Since SciPy 1.9, we now have a lazy import mechanism which allows us to do `import scipy` and then work on any submodules without waiting time due to the import itself.
NumPy and Pandas, just to name these, have set a precedence for an idiomatic way of importing their library. This is arguably an advantage for introspection, debugging, teaching, consistency or even communication purposes. Hence, I would like to propose that we also adopt an idiomatic import style for SciPy.
We also have an idiomatic way, which is documented at http://scipy.github.io/devdocs/reference/index.html#guidelines-for-importing... and used throughout our docs and by users and downstream packages. There's basically 3 ways of doing this, if we'd start from scratch: 1. import scipy.submodule # use as scipy.submodule.func() 2. import scipy as sp # use as sp.submodule.func() 3. from scipy import submodule # use as submodule.func() It's not clear which would be preferred if we'd have the luxury of starting from scratch. Whole blog posts have been written about abbreviations like `np` and `pd` being an anti-pattern for example, and the justification of doing that in scipy is far weaker before our main namespace is essentially empty, while for numpy you use it all the time so the 3 characters saved matter a lot more. Given the large amount of churn a change would cause and the quite limited (if any) benefits here, I'd prefer to not change anything here. Cheers, Ralf If we would want to move forward with that idea, I would propose to make a
brainstorming session with interested people to discuss the topic. This could for instance be a topic for next week’s community call.
Cheers, Pamphile
_______________________________________________ SciPy-Dev mailing list -- scipy-dev@python.org To unsubscribe send an email to scipy-dev-leave@python.org https://mail.python.org/mailman3/lists/scipy-dev.python.org/ Member address: ralf.gommers@gmail.com
participants (3)
-
Pamphile Roy -
Ralf Gommers -
Ross Barnowski