Tested on the ESP32. Works (duh) but doesn't handle soft resets very well - after reading the code and realizing how soft resets work, I came to a conclusion that randomly placing global, lazily initialized variables won't work so well...

Need to figure out how to do this nicer. Perhaps if there was a special data section that mp_init would automatically run memset(0) on, or something like that.

Need to figure out how to do this nicer. Perhaps if there was a special data section that mp_init would automatically run memset(0) on, or something like that.

Otherwise, the only solution I see is to manually add each item to MP_STATE_VM. And by the way, perhaps some, or even many, of the items in MP_STATE_VM could be moved to such a section, instead of being selectively placed in a global struct. I'd find it nicer.

I came to a conclusion that randomly placing global, lazily initialized variables won't work so well...

What made you give up on previous approach of compile-time tuple generation?

What made you give up on previous approach of compile-time tuple generation?

You mean #4468?

You mean #4468?

Yep.

Can't say I've given up on it. I still think it's a better approach. But I wanted to gather some more approval before continuing with it, and meanwhile I thought to offer this PR to show another softer, possible way, and see what's favoured more.

If you think the first solution is better and viable, I'll continue with it.

Yes, I personally think that having fully static, ROMable data is better. And this "lazy globals" stuff is too magic. Before going for things like that, we'd rather firsy solve the issue of letting override sys.stdout and friends, I probably already mentioned that.

Thanks for the attempt @Jongy . You can see that getting all the fine details correct is not easy. The cached list of builtins would need to be stored in the root pointer section (as you found out) making it more complex. And a downside of the approach here is that (with the feature enabled) all modules grow by 1 word, even though most won't use the lazy feature. That could be solved by putting the lazy function pointer in the modules dict (somehow), or making mp_obj_module_t flexible in size (eg there is mp_obj_module_extra_t which has this extra lazy pointer only for those modules that use it).

At this point I don't think the utility of having sys.builtin_module_names outweighs the complexity introduced here in the implementation. That could change if there were other compelling uses for the lazy attr (which could be extended to store, not just load).

The ROM approach is probably going to be even more complicated, but hard to say until there is a working proof of concept. In the end there may not be an elegant way to implement the feature.

The ROM approach is probably going to be even more complicated, but hard to say until there is a working proof of concept

I agree, basically :)

Since this approach really got too complicated, and since I already have a functioning PoC of the ROM approach, I'll close this PR. Back to #4468.