Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.3k
py/runtime.c: Add support for using __all__ in star import.#17331
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
88a3d7b
tofa6f6c0
Comparecodecovbot commentedMay 20, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@## master #17331 +/- ##======================================= Coverage 98.56% 98.57% ======================================= Files 169 169 Lines 21950 21968 +18 =======================================+ Hits 21636 21654 +18 Misses 314 314 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
github-actionsbot commentedMay 20, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Code size report:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
On the other hand, limiting imports to a subset of symbols rather than importing most of them in the parent globals will be reduce RAM usage
If the module containing__all__
has to be loaded in RAM (e.g. it is a .py file), then wouldn't RAM usage actually increase because of the extra list (unless there are significantly more "private" members not starting with "_" than public)?
(Not saying we shouldn't accept this, just want to make sure the details are clear.)
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
fa6f6c0
to8ddf09c
Compare
It will of course depend on the cases. You are correct in saying that for simple modules, default import is likely to work as well. However for more complex modules that use imports, those imported symbols would typically be unnecessarily re-exported in the parent global dictionary by a star import. |
30ceed9
toc3527de
Comparec3527de
toaaea1e5
Compare(force-pushed today after rebased to head revision) |
Thanks for this. The "TODO" for this feature has definitely been there a long time, more than 11 years! It would be nice to see this take up less code size, but I can't see a way to reduce it. Well, at least it's guarded by a config option, and I agree "basic" level is a good level to enable it at. |
a68b9cf
to93d2da2
CompareWhen the symbol `__all__` is defined in a module, `mp_import_all()` shouldimport all listed symbols into the global environment, rather than relyingon the underscore-is-private default. This is the standard in CPython.Each item is loaded in the same way as if it would be an explicit importstatement, and will invoke the module's `__getattr__` function if needed.This provides a straightforward solution for fixing star import of modulesusing a dynamic loader, such as `extmod/asyncio` (see issuemicropython#7266).This improvement has been enabled at BASIC_FEATURES level, to avoidimpacting devices with limited ressources, for which star import is oflittle use anyway.Additionally, detailled reporting of errors during `__all__` import hasbeen implemented to match CPython, but this is only enabled whenERROR_REPORTING is set to MICROPY_ERROR_REPORTING_DETAILED.Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
93d2da2
to66c0148
Compare66c0148
intomicropython:masterUh oh!
There was an error while loading.Please reload this page.
Summary
If a module defines the symbol
__all__
, that definition should be used when doing a wildcard import: all listed symbols and no others should be added to the parent global environment. This is the standard in CPython.This pull requests fixes a longtimeFIXME in
mp_parse_all
to implement this behaviour.Each item is loaded in the same way as if it would be an explicit import statement, including invoking the the module's
__getattr__
function if needed. This provides a straightforward solution for fixing star import of modules using a dynamic loader, such asextmod/asyncio
(see issue#7266, dated 2022).Testing
The corresponding test cases have been added to
tests/import
, including the default behaviour when__all__
is not defined.As star imports are not expected to be useful on systems with very limited ressources, this improvement is only enabled for ports at BASIC_FEATURES level. In order to skip the new test cases on builds at lower feature level, the test file checks for the availability of another feature enabled at the same level (next's 2nd argument).
Trade-offs and Alternatives
This improvement will slightly increase the code size, for the sake of CPython compatibility.
On the other hand, limiting imports to a subset of symbols rather than importing most of them in the parent globals will be reduce RAM usage. The feature also fixes a longstanding issue with dynamic loading of modules, which is another method used to reduce RAM usage.