py: rename array module to uarray #4449
Conversation
|
Thanks. But I'm not sure if it's worth to enable weak links in unix port just for one module. How about just to re-add "array" alias name via MICROPY_PORT_BUILTIN_MODULES until the next release? |
I don't think that will work, in the sense that it will always be found first and so an
Well, I wanted to enable it anyway, and add many links there, so the unix binary can emulate CPython more closely without needing a set of libraries on the filesystem. |
How about all the concerns that it adds more confusion than benefits? |
|
I find the fact that it doesn't behave like the bare metal ports to be more confusing than the way it behaves now. |
|
So, as usual, confusion comes in layers. Baremetal ports behaves confusing by offering fake "CPython compatibility". Then to some people the fact that unix port doesn't fake it is also confusing, and it goes in rounds and in circles. The well-known solution is to cut solution where it begins. The worst solution is to make confusion all-encompassing and unescapable. |
MicroPython is intended to provide a faithful as possible implementation of Python, with modules included where possible.
So is the proposal to remove weak links altogether and make |
As you understand, in this case, "as faithful as possible" would be "allowing to implement as complete as possible API of CPython in the obvious way, by clearly separating what's MicroPython API and not hogging namespaces which don't belong to it".
As you very well understand either, I hardly could realistic propose that, even though I definitely try to maintain a view opposing weak links (so the truth was somewhere in the middle). My point would be to try to define well what weak links are. In my view, it is a product-specific feature, offered by vendors of specific products as a feature to their users to smooth the curve of learning "native MicroPython". On the level of the language itself, it's an ugly hack, which despite its good intentions, leads to the opposite effect - people don't learn how to use native MicroPython well, and instead remain in permanent confusion regarding what MicroPython vs CPython are. Anyway, beyond paradigmatic aspect of it, I have a specific proposal: how about dropping all those growing data structures to maintain, and add following code (under the config option of course):
Done like that, it should be clear to anyone that it's nothing but a special-purpose hack. Should save some bytes, too. |
|
Ok, so can we finish with this in obvious least effort/least scope creep way: a) proceed with the rename; b) for ports which already have weak links enabled, add a weak link; c) for ports which don't use weak links, just have 2 entries "array" and "uarray" pointing to the same module. This will allow to normalize docs, and that's the main driver for the, change, and seeing how to allow to actually override "array" consistently can be dealt with as a next task. |
This commit implements automatic module weak links for all built-in
modules, by searching for "ufoo" in the built-in module list if "foo"
cannot be found. This means that all modules named "ufoo" are always
available as "foo". Also, a port can no longer add any other weak links,
which makes strict the definition of a weak link.
It saves some code size (about 100-200 bytes) on ports that previously had
lots of weak links.
Some changes from the previous behaviour:
- It doesn't intern the non-u module names (eg "foo" is not interned),
which saves code size, but will mean that "import foo" creates a new qstr
(namely "foo") in RAM (unless the importing module is frozen).
- help('modules') no longer lists non-u module names, only the u-variants;
this reduces duplication in the help listing.
Weak links are effectively the same as having a set of symbolic links on
the filesystem that is searched last. So an "import foo" will search
built-in modules first, then all paths in sys.path, then weak links last,
importing "ufoo" if it exists. Thus a file called "foo.py" somewhere in
sys.path will still have precedence over the weak link of "foo" to "ufoo".
See issues: #1740, #4449, #5229, #5241.
This commit implements automatic module weak links for all built-in
modules, by searching for "ufoo" in the built-in module list if "foo"
cannot be found. This means that all modules named "ufoo" are always
available as "foo". Also, a port can no longer add any other weak links,
which makes strict the definition of a weak link.
It saves some code size (about 100-200 bytes) on ports that previously had
lots of weak links.
Some changes from the previous behaviour:
- It doesn't intern the non-u module names (eg "foo" is not interned),
which saves code size, but will mean that "import foo" creates a new qstr
(namely "foo") in RAM (unless the importing module is frozen).
- help('modules') no longer lists non-u module names, only the u-variants;
this reduces duplication in the help listing.
Weak links are effectively the same as having a set of symbolic links on
the filesystem that is searched last. So an "import foo" will search
built-in modules first, then all paths in sys.path, then weak links last,
importing "ufoo" if it exists. Thus a file called "foo.py" somewhere in
sys.path will still have precedence over the weak link of "foo" to "ufoo".
See issues: micropython#1740, micropython#4449, micropython#5229, micropython#5241.
Following the other modules like ustruct, ucollections. See issues micropython#4370 and micropython#4449.
This commit implements automatic module weak links for all built-in
modules, by searching for "ufoo" in the built-in module list if "foo"
cannot be found. This means that all modules named "ufoo" are always
available as "foo". Also, a port can no longer add any other weak links,
which makes strict the definition of a weak link.
It saves some code size (about 100-200 bytes) on ports that previously had
lots of weak links.
Some changes from the previous behaviour:
- It doesn't intern the non-u module names (eg "foo" is not interned),
which saves code size, but will mean that "import foo" creates a new qstr
(namely "foo") in RAM (unless the importing module is frozen).
- help('modules') no longer lists non-u module names, only the u-variants;
this reduces duplication in the help listing.
Weak links are effectively the same as having a set of symbolic links on
the filesystem that is searched last. So an "import foo" will search
built-in modules first, then all paths in sys.path, then weak links last,
importing "ufoo" if it exists. Thus a file called "foo.py" somewhere in
sys.path will still have precedence over the weak link of "foo" to "ufoo".
See issues: micropython#1740, micropython#4449, micropython#5229, micropython#5241.
adventure together with rotary trinkey
And provide backwards compatible weak link so that
import arraystill works.See #4370