os Vs uos rabbit hole

[KJM]

I try to stay on the straight & narrow but sometimes I fall into rabbit holes. I've been running a .py program for ages, when I was finally happy with it I changed it to a .mpy whereupon it crashed at

Code: Select all

import binascii; boundary=binascii.hexlify(os.urandom(16)).decode('ascii')

with

Code: Select all

line 233 NameError: name uos isnt defined

presumably because I import os instead of uos at the top of the program. The rabbit hole is I don't understand why os was near enough to uos for the .py version?

[stijn]

So your code does

Code: Select all

import os
os.urandom

yet it fails saying uos isn't defined? Can you reproduce that with the minimal sample above? Sounds like a bug.

[KJM]

So first I run

Code: Select all

import os
print('esp32', uos.urandom(16))

from the IDE as a .py & get

Code: Select all

esp32 b'\x05t46#\x06%\xb6<\xb6\x81U\xceQ\x18\xa1'

then I convert the orginal .py above to code.mpy & upload it onto the esp32, then I type

Code: Select all

import code

into the IDE & get

Code: Select all

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "code.py", line 3, in <module>
NameError: name 'uos' isn't defined

which is understandable since I haven't imported uos but why is uos OK for the .py version?

[stijn]

Hard to tell. I mean, I'd say 'this is an implementation detail and the key is in the source code' but I'm actually not sure. I also cannot reproduce it on the unix port for example. The 2 cases you describe differ in more than just .py vs .mpy. First one is 'run from IDE', not sure what that means but it might be doing something behind the scenes where it actually imports uos.

[jimmo]

So first I run

import os
print('esp32', uos.urandom(16))

This shows the issue -- you're importing os, but using uos. Something else is importing uos (which is true, see below).

but it might be doing something behind the scenes where it actually imports uos.

stijn is right -- this is a particular quirk of ESP32 where the filesustem initialisation and loading is implemented in Python, and that code imports uos. (See https://github.com/micropython/micropyt ... s/_boot.py )

In general, the advice is to never directly import or use the "u" modules. So import "os" and use os.urandom.

(I know this hasn't always been particularly clear advice, but we've been trying to improve this lately. For example the docs don't mention "ufoo" anywhere anymore, other than this one note here: https://docs.micropython.org/en/latest/ ... rom-python )

[KJM]

It would be nice not to have different code for .py & .mpy files. Is there any harm in 'import uos' in .py files so they can run as .mpy files too?

[jimmo]

It would be nice not to have different code for .py & .mpy files. Is there any harm in 'import uos' in .py files so they can run as .mpy files too?

You can use either. My point is that you just need to use "uos.urandom" if you "import uos", or "os.urandom" if you "import os".