Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:  +440 +0.055% standard[incl +192(data)]
      stm32:  +112 +0.029% PYBV10
     mimxrt:  +104 +0.029% TEENSY40
        rp2:  +132 +0.040% PICO
       samd:  +108 +0.040% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

Merging #11740 (ca79b49) into master (ed962f1) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master   #11740   +/-   ##
=======================================
  Coverage   98.40%   98.40%           
=======================================
  Files         155      155           
  Lines       20543    20543           
=======================================
  Hits        20215    20215           
  Misses        328      328           

Strange that there is such a large increase in code size...

Strange that there is such a large increase in code size...

It's entirely the uasyncio.py wrapper. It compiles to an 83 byte .mpy file.
In my local build, firmware goes from 362804 bytes without it to 362936 bytes with it frozen (i.e. +132 bytes).

We could maybe add a reverse-weak-links-for-frozen-modules feature (i.e. an alias() command in manifest.py?)

We could maybe add a reverse-weak-links-for-frozen-modules feature

Yes, if it's purely done for backwards compatibility and there's a way to do it in fewer bytes in C, then I think we should try that.

We could maybe add a reverse-weak-links-for-frozen-modules feature

Yes, if it's purely done for backwards compatibility and there's a way to do it in fewer bytes in C, then I think we should try that.

An alias is a bit tricky because there are 7 asyncio modules frozen.

A very simple option is to detect an import path starting with uasyncio and map it. e.g. in builtinimport.c

    #if MICROPY_PY_ASYNCIO
    // If the import is for "uasyncio" or "uasyncio/...", then map to "asyncio".
    if (strncmp(module_name, "uasyncio", 8) == 0 && (module_name[8] == '.' || module_name[8] == 0)) {
        ++module_name;
        --module_name_len;
    }
    #endif

This comes out about 100 bytes better than adding uasyncio.py. However it's maybe a bit weird to unconditionally remap uasyncio at the top-level import. (Although this is only a backwards compatibility break if someone previously had an uasyncio.py in their filesystem and had MICROPY_PY_UASYNCIO enabled, which would be a bit strange).

You could also do this in frozenmod.c but then you have a situation where import asyncio followed by import uasyncio will cause a double-import.

Let's keep the frozen uasyncio.py as-is, and optimise frozen code some more later on.

Merged!

I'm very happy this has been merged, thanks @jimmo

Minor note for anyone playing along at home - I have an existing project where I wanted compatibility with an existing cpython library using asyncio so in my main.py I have

import uasyncio as asyncio
sys.modules["asyncio"] = asyncio

before importing the external library, such that when it does import asyncio it "just worked".

With micropython updated to include this MR, well my snippet above blows up with an infinite recurtion error in the new uasyncio __getattr__! Certainly an easy fix, just had to remove my old workaround!