FYI: The u-prefix has been removed from MicroPython modules.

[jimmo]

Hi,

Summary: This is an entirely backwards-compatible change, and you don't need to change anything, but FYI you can simplify your imports. Please don't write import utime or import uasyncio any more (write import time and import asyncio instead).

In the past couple of months we've merged a series of pull requests that has renamed built-in and frozen modules to remove the u-prefix.

There's a bit of history here but for many years the built-in modules (e.g. os, sys, etc) were actually named uos, usys. This was done for a few reasons [1]. In order to make it possible for existing CPython code to "just work", a mechanism was implemented (known as "weak links") to allow import os, etc to work.

For built-in modules this was mostly invisible, although it led to some slightly surprising things (e.g. help("modules") listed the u-prefixed names). The main limitation was that it only applied to built-in modules written in C, and any Python modules that are frozen into the firmware didn't get this weak links mechanism, so for example urequests and uasyncio always had to be imported with the u-prefix. This just led to confusion and unfortunate code like import umodule as module or worse:

try:
  import uasyncio as asyncio # Running on MicroPython
except ImportError:
  import asyncio  # Running on CPython

So in v1.21 (which will be released soon), all built-in modules have been renamed to match their CPython name -- os, sys, json, etc. The only exception is uctypes which is completely different to CPython's ctypes so it will keep its uctypes name. Additionally uasyncio and urequests have been renamed to asyncio and requests.

There is a lot of existing code out there that use the u-prefix, e.g. import uos or import urequests so this will continue to work (for both C and Python modules) [2]. But please prefer to use just the non-u-prefixed name from now on. [3]

Going forward, the MicroPython team are going to make it a policy to make built-in modules with the same name as CPython modules only implement subsets of the CPython version. (This is very similar to CircuitPython's policy). There are obviously many historical exceptions to this, but we will not be adding more MicroPython-specific methods like time.ticks or os.mount or additional kwargs/args on methods that are not supported in CPython [4]. So over time these methods or functionality may be added to other non-CPython modules, but we do no not plan to break backwards compatibility in the v1.x series of releases by removing them from their existing modules. In MicroPython 2.x we may revisit this.

Please let me know if you have any questions!

---

[1] This was initially to indicate that this is the MicroPython version of the module, and may differ from the CPython version, but primarily it has been used to allow another mechanism where a built-in module can be extended in Python. This will continue to work, but we now additionally support a clearer way of achieving the same thing using sys.path. See https://docs.micropython.org/en/latest/library/index.html#extending-built-in-libraries-from-python

[2] For built-in C modules this works in the reverse of the old weak links mechanism. For library modules, we include a shim ufoo.py that forwards to foo. See for example https://github.com/micropython/micropython/blob/master/extmod/asyncio/uasyncio.py and https://github.com/micropython/micropython-lib/tree/master/micropython/urequests

[3] If you need your code to continue to work unmodified on older MicroPython versions, then you will need to continue to use uasyncio and urequests. However it has never been necessary to use e.g. import utime for built-in modules (which is why we removed all mention of the u-prefix names from the documentation a couple of years ago).

[4] This is not a simple policy to apply! For example in the recent PR to add compression support to MicroPython, we ended up having to provide deflate.DeflateIO rather than CPython's gzip.GZipFile even though the two are basically identical, but we needed one extra parameter that GZipFile does not support. See #11905 and micropython/micropython-lib#694 (which provides a CPython-compatible wrapper).

[jimmo]

Just to clarify the current state as of today. All of the above applies to the upcoming v1.21 release. The current nightlies have the changes for built-in C modules (os, sys, etc) as well as asyncio. The micropython-lib submodule has not been updated yet, so the urequest rename isn't in the nightlies yet.

[bidrohini]

What should we write now instead of import utime?

[jimmo]

import time

[bidrohini]

Thanks a lot. It is really an important info.

[theacodes]

Just wanted to say that I'm super thrilled to see this change. Bringing MicroPython's standard library closer to CPython and CircuitPython will make a lot of code easier to carry across implementations and will strengthen the ecosystem for all of us. Thank you for doing this, and all of the amazing work y'all do on MicroPython. 💜

[jimmo]

Thanks @theacodes!!

[encukou]

Hello,

we ended up having to provide deflate.DeflateIO rather than CPython's gzip.GZipFile even though the two are basically identical, but we needed one extra parameter that GZipFile does not support

Would it make sense to add this parameter to CPython?
CPython 3.11 added wbits for zlib.compress, but it's not exposed in GZipFile.

[jimmo]

@encukou Yep definitely something we considered. I'd be surprised if CPython was willing to do this though as wbits=31 is kind of baked implicitly into the gzip specification, which is why (unlike the zlib header) the gzip header doesn't include the window size.

But...going forward, working with the Python team to add MicroPython-relevant improvements to Python that are also beneficial to Python is something I'd like to do. For example, we've long wanted to make some simple improvements to memoryview to make it possible to do common tasks with zero allocations, and I think this is a good candidate.

[smurfix]

Next up: add readinto and related methods to CPython.

[jimmo]

@smurfix Not sure I follow... CPython does have readinto?

[smurfix]

Yes, binary files have that method, but _io.TextIOWrapper et al. does not.

[jimmo]

@smurfix This is actually a MicroPython bug... our text-mode files shouldn't either. On CPython you can use f.buffer.readinto if f is a text-mode file.

MicroPython is currently missing .buffer on anything except the stdio text mode streams though, which is something we should fix (maybe after #12091). It's pretty straightforward to implement.