Skip to content

docs: Replace "umodule" with "module" everywhere. #5377

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

Closed
wants to merge 4 commits into from

Conversation

jimmo
Copy link
Member

@jimmo jimmo commented Dec 4, 2019

The "import module" vs "import umodule" is something of a FAQ, and it comes up on the forum and when I'm teaching MicroPython in-person.

In summary -- my experience has been that most people don't care about the subtle distinction between "uos" and "os". I understand and agree with the argument that the "u" is a reminder that it's the "micro" version, but I don't think it outweighs the confusion. It's one of the first things that you see in the documentation, but I don't think it's one of the first things you need to know as a beginner MicroPython programmer. Your existing Python code should just work, and the MicroPython documentation should match the idiomatic way to write code.

I think since #5241 was merged, we're in quite a good situation:

  • People can consistently use "import foo" across all ports. (with the exception of the minimal ports)
  • The ability to override/extend via "foo.py" continues to work well.

This PR updates the documentation such that:

  • All ufoo.rst is now foo.rst
  • Updates all internal references in the docs to exclusively use "foo" not "ufoo".
  • Updates library/index.rst to simplify the explanation of module naming and move the "ufoo" part to an extra detail at the end for people who care.

Note: the replacements were done with a quick script, so they aren't perfect and will need some manual fixups (e.g. I can see that the very first diff is "requests" which should probably be still "urequests"...). But before I do the manual cleanup, I'd like to get some feedback on whether people think this is a worthwhile change.

Refs:

@MrSurly
Copy link
Contributor

MrSurly commented Dec 4, 2019

Last I checked (a while ago), the Unix port did not have aliases for <module> --> <umodule>

@jimmo
Copy link
Member Author

jimmo commented Dec 4, 2019

Last I checked (a while ago), the Unix port did not have aliases for -->

This was implemented in #5241

The existing weak links system (used on STM32/ESP32/ESP8266) was replaced with an automatic rule to alias foo to ufoo if it exists (now enabled on most ports).

@MrSurly
Copy link
Contributor

MrSurly commented Dec 4, 2019

This was implemented in #5241

Okay then. =)

@dpgeorge dpgeorge added the docs label Dec 4, 2019
@hoihu
Copy link
Contributor

hoihu commented Dec 5, 2019

completly agree with the arguments, +1.

And after all we do have a „micro“ - in „micropython“ (or „upy“) so we still have the „u“ 😉. I just wished upy would have been chosen rather than mpy.

@tannewt
Copy link

tannewt commented Dec 5, 2019

Has there been any discussion about moving non-standard APIs out of modules that share a name with CPython? Managing filesystems (http://docs.micropython.org/en/latest/library/uos.html?highlight=uos#filesystem-mounting) is one example. In CircuitPython, we moved these APIs to a separate storage module. That way code written in MicroPython will then work in CPython.

@dpgeorge
Copy link
Member

dpgeorge commented Dec 6, 2019

Has there been any discussion about moving non-standard APIs out of modules that share a name with CPython? Managing filesystems is one example

There was some related discussion about a "storage" module in #4772 (comment)

I do understand the arguments for doing this, moving non-CPython stuff out of CPython-named modules. But it's not easy. For example, what about time.sleep_ms(), time.ticks_ms() and uzlib.DecompIO (none of those exist in CPython)? And also minor additions like extra args to existing CPython functions/methods. In the end a u-module is not a strict subset of the corresponding CPython module but rather has a (large) overlap with it, and so one can write Python code that runs under both CPy and uPy that uses only the overlap.

Moving all the uPy-specific filesystem stuff out of uos into a uPy-specific module is pretty easy to do (and make backwards compatible), and may be a good idea, something to look in to. But some of the other stuff is much harder to separate.

@mzdaniel
Copy link
Contributor

mzdaniel commented Dec 8, 2019

For learnability and aesthetics perspective, simplifying namespaces is a big +1. As Jimmo mention and as instructor myself, using "module" everywhere instead of "umodule" is important while teaching Python. For example, a bicycle is not expected to acelerate as much as an airplane, but the aceleration concept is the same regardless of the name.

Compatibility wise, it isn't a particularly pleasant experience to have to wrap code in try/except blocks for obvious namespaces just to 'teach' the computer where to find the functionality people need, making code much harder to read, write, and reason about.

jimmo added 4 commits August 12, 2021 15:32
This is a simple rename of the files, no content changes
(other than updating index.rst to use the new paths)

Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Anywhere a module is mentioned, use it's "non-u" name for consistency.

Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Adds section about extending built-in modules from Python.

Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
@codecov-commenter
Copy link

codecov-commenter commented Aug 12, 2021

Codecov Report

Merging #5377 (f69cc41) into master (42d1a16) will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5377      +/-   ##
==========================================
- Coverage   98.30%   98.29%   -0.02%     
==========================================
  Files         154      154              
  Lines       20014    20014              
==========================================
- Hits        19675    19673       -2     
- Misses        339      341       +2     
Impacted Files Coverage Δ
py/obj.c 97.22% <0.00%> (-0.40%) ⬇️
py/runtime.c 99.39% <0.00%> (-0.16%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42d1a16...f69cc41. Read the comment docs.

@jimmo
Copy link
Member Author

jimmo commented Aug 12, 2021

I have rebased this and sorted out the manual fixups. Also a bit of a reword of the overview in library/index.rst.

The two remaining u-libraries mentioned in the docs are uctypes (which has almost no overlap with ctypes) and ureqests. The former I suggest we rename to ntypes or native or something (leaving uctypes as an alias) in a separate PR, and urequests is in micropython-lib anyway and not subject to weak links.

One thing I just realised is that we're now going to break any existing docs links to the latest tag. e.g. https://docs.micropython.org/en/latest/library/uos.html is now https://docs.micropython.org/en/latest/library/os.html I guess three options (in order of preference):

  • Add placeholder/redirect ufoo.rst --> foo.rst
  • Only rename the content, not the files
  • Do nothing, the 404 page gives a link back to the docs home page.

@jimmo jimmo changed the title RFC: docs: Replace "umodule" with "module" everywhere. docs: Replace "umodule" with "module" everywhere. Aug 12, 2021
@dpgeorge
Copy link
Member

Add placeholder/redirect ufoo.rst --> foo.rst

I should be able to do this on the server side.

@jimmo
Copy link
Member Author

jimmo commented Aug 13, 2021

I should be able to do this on the server side.

It's weak links all the way down :)

Thanks, sounds perfect.

@dpgeorge
Copy link
Member

Merged in 2186063 through d7fbc75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants