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.

Sign up for GitHub

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

Jump to bottom

py/objmodule.c: Implement default weak links for all ports. #5229

Closed
wants to merge 3 commits into from
Closed

py/objmodule.c: Implement default weak links for all ports. #5229

wants to merge 3 commits into from

Conversation

jimmo
Copy link
Member

@jimmo jimmo commented Oct 18, 2019 •
edited

I use the Unix port a lot for testing and keep tripping over this. I very strongly agree that the modules should be called ufoo but also really like the weak linking behaviour so that code "just works" while still providing a nice mechanism for customisation and extension. After seeing a couple of recent forum posts about this, I looked through the history on #1740 and I'd like to propose that we just do this.

This also avoids duplication in the ports and avoids a port "accidentally" missing a weak link (although I didn't notice any existing cases of this).

I'm not aware of any effect this will have on existing code. (Please correct me if I've missed anything here). If you're extending/overriding built-in modules (e.g. using os from micropython-lib) then that will take precedence over the weak links, so will continue to function as it does currently.

Previously ports chose whether or not to alias ufoo -> foo, and each
port implemented this explicitly. This changes objmodule to always provide a
foo weak link for any core ufoo module.

Other than now enabling weak links for the Unix port, this should be a
no-op on any ports currently enabling weak links.

utime and uos are provided by the ports, so they must still provide
their own weak links for these modules.

Fixes #1740

@jimmo
py/objmodule.c: Implement default weak links for all ports.
ef65c2b 
Previously ports chose whether or not to alias `ufoo` -> `foo`, and each
port implemented this explicitly. This changes objmodule to always provide a
`foo` weak link for any core `ufoo` module.

This should be a no-op on any ports currently enabling weak links.

`utime` and `uos` are provided by the ports, so they must still provide
their own weak links for these modules.

Fixes micropython#1740
@kevinkk525
Copy link
Contributor

I strongly agree that the Unix port needs to be compatible to the other ports. It's a very useful tool for testing.

@stinos
Copy link
Contributor

stinos commented Oct 18, 2019

Can you add a comment in the commit message about the effect this has (if any) on os and other libraries from micropython-lib installed via upip or similar?

@jimmo
Copy link
Member Author

jimmo commented Oct 18, 2019

Can you add a comment in the commit message about the effect this has (if any) on os and other libraries from micropython-lib installed via upip or similar?

@stinos I am not aware of any meaningful effect this will have. I've updated the PR description.

The only thing I can think of is if code uses the presence of (for example) uos vs os to change its behaviour, in any way other than to just go ahead and import the other one. I haven't been able to think of any reason why someone would do that...

@stinos
Copy link
Contributor

stinos commented Oct 18, 2019

Sorry it's just that I don't know how weak links are implemented so I was thinking of what happens for example when os from micropython-lib is installed. Will import os still import that, or will it import the linked uos, and break existing behaviour?

@dpgeorge
Copy link
Member

I don't know how weak links are implemented so I was thinking of what happens for example when os from micropython-lib is installed. Will import os still import that, or will it import the linked uos, and break existing behaviour?

Weak links are effectively the same as having a set of symbolic links on the filesystem that is searched last. So an import os will search built-in modules first, then all paths in sys.path then weak links last.

@dpgeorge
Copy link
Member

See also #4449 for related discussion.

@peterhinch
Copy link
Contributor

I strongly agree that the Unix port needs to be compatible to the other ports. It's a very useful tool for testing.

Agreed. The coverage build is better for testing/support because it includes all MicroPython features. I think the standard Unix build should be the same.

@dpgeorge dpgeorge mentioned this pull request Oct 21, 2019
Closed
@dpgeorge
Copy link
Member

See #5241 for an alternative to this.

dpgeorge added a commit that referenced this pull request Oct 22, 2019
@dpgeorge
py: Automatically provide weak links from "foo" to "ufoo" module name.
d2384ef 
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.
@dpgeorge
Copy link
Member

Superseded by #5241

@dpgeorge dpgeorge closed this Oct 22, 2019
alu96 pushed a commit to alu96/micropython that referenced this pull request Mar 23, 2020
@dpgeorge
py: Automatically provide weak links from "foo" to "ufoo" module name.
b416606 
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.
c0d3z3r0 pushed a commit to c0d3z3r0/micropython that referenced this pull request Apr 5, 2020
@dpgeorge @pfalcon
py: Automatically provide weak links from "foo" to "ufoo" module name.
d0ac76d 
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.
tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Aug 27, 2021
@jepler
Merge pull request micropython#5229 from warmbit/warmbit_bluepixel
c174b7c 
add warmbit_bluepixel
@jimmo jimmo mentioned this pull request Aug 5, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
py-core
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

unix: struct/ustruct not consistent with pyboard
5 participants
@jimmo @kevinkk525 @stinos @dpgeorge @peterhinch