Python module support is not yet implemented

[pfalcon]

Not trying to cause any hassle, but instead to have fact recorded, and possible to get some comments regarding planning and issues related to implementation.

So, "import" statement (well, import() builtin func) is currently not implemented (just dumps its args), and mp_module_new() has following comment:

// temporary way of making C modules
// hack: use class to mimic a module

I understand that full-fledged modules support is probably not top-priority for MCU port - being able to create C modules and using just single main Python app already allows to do a lot of things. But sooner or later it will be needed - that's what we all expect from Python - being easily to reuse 3rd-party modules, right? (Actually #7 already touched on that.) And "unix" port is pretty orphaned without it.

So, any planning/ETA when this might be implemented? Any blockers on the road? For example, I don't know if all needed things on core side are there, but I may imagine there're many "boring" questions like modules search paths, then differences between search paths/mehods for ports (MCU vs unix), support for precompiled bytecode files, etc. etc.

[dpgeorge]

Yep, import is not yet functional :) This was pretty much the next thing on my list to get working, since I know it's very important, and I can't really call it Micro Python if it ain't got import/modules.

There are no road blocks, I just need time to implement it. The compiler emits correct import code, all the framework is there to run "import" when needed, and module-level variables (dictionary) is already being used for the main script.

[Neon22]

I'm hoping to help with this issue by doing the following. Can you guys validate if this is a good idea - or if the import module for micropython will take care of it ?

It makes a minmal set of python code by copying and stripping unused functions out of imported modules.
First - it processes the tree of imports from all python files.
Second - it copies these files to a new subdirectory, renames them and their respective imports so the new files are loaded instead of the original modules.
Third - it removes all unused code from these files.
The end result is a minimal python setup which will have the smallest memory footprint.

It is one way to solve the problem, but the import preprocessor could also strip out unused functions (I think).

Is this a useful thing to do ?
Its here: https://github.com/Neon22/python-flavin

[pfalcon]

@dpgeorge: Good plan, thanks!

[pfalcon]

@Neon22: Regardless of how uPy module system will work, I guess your tool is useful. I hope you tried to search prior art to avoid reinventing a wheel (but I personally never heard of such tool for Python). Also I hope you keep in mind that in general case it's not possible to do what you want in a dynamic language ;-). Because for example you can do obj.getattr("do_" + method)(). So, I hope you'll balance automation and heuristics vs user configurability. Java's ProGuard as used e.g. by Android can be example of production-quality tool which does this stuff. All in all, this is worth a separate space to discuss (yeah, we'll need forum in some time ;-). Hope someone indeed helps Damien with that to let him do hacking, which noone else can do ;-).)

[dpgeorge]

@Neon22: the upython code will not do any of this. It will act as normal CPython does and read in the right Python script, compile/run it, and assign global names as appropriate. Any minification, as you suggest, would need to be done by a preprocessor. So your tool would be useful, but I wouldn't classifiy it as a priority.

[dpgeorge]

Basic import is now working. Still some things to fix up so I'll keep this issue open.

[pfalcon]

Basic import indeed works, so let's close this and open more feature-detailed tickets as needed.