This came up in https://github.com/micropython/micropython-lib/pull/693

It does seem reasonable to expect that A = micropython.const(1) should do the right thing, but it only works if you write A = const(1). I would argue that the former should raise an error or otherwise indicate that it's not doing anything useful.

We need to support from micropython import const because this facilitates:

1. Running MicroPython code on CPython (where you have a micropython.py that provides a dummy const function).
2. On builds with MICROPY_COMP_CONST disabled (e.g. when settrace is enabled) there will be no "magic" const, so it needs to be imported.

I think 791b65f4b261a23e427664f0b86ce32b60e33cb5 confirms the above.

Some ideas:

1. We could change parse.c to turn const(...) into a no-op, rather than not handling it at all when MICROPY_COMP_CONST is disabled. (I never realised until today that we had this implicit requirement to use from micropython import const to be able to use const() in all builds, I have written a lot of .py files that don't do this!). Then micropython.const should no longer be the identity function (it should raise an error).

or

2. Only if MICROPY_COMP_CONST is enabled, then micropython.const should no longer be the identity function (it should raise an error to indicate incorrect usage).

or

3. Make the parser also handle micropython.const.

My preference would be #1. Instead of making micropython.const raise an error, it could also just be None (enough to make the import work), but then it might be a bit confusing to figure out why it's failing.