Oops, I just noticed issue #298 also references this topic. Apologies for duplicating stuff.

One quick comment is that if __name__ == "__main__": idiom is not yet working.

Oops. I apparently was wrong, it works.

Thanks for report. This is definitely STM-specific issue, and is regression from #258 - I hoped that @dpgeorge will follow with changes for stm, but apparently, that slipped (I shouldn't have left it in such state). #309 posted which should fix the issue, but note that it's not tested (I don't work with bare-metal ports so far), so please help testing.

Okay, I have tried this with the latest build and it works, with 1 change: I renamed test_module.py to testm.py to fit within the 8.3 filename limit. The 8.3 filename restriction should be lifted, soon :)

Note that you can use CTRL-C at the minicom prompt to break out of the infinite loop. It'll then pop you into REPL. CTRL-D will then soft-reset, taking you back to the main.py program.

I have also tried this and can confirm that it works when renaming the test module to testm.py. I also tried the import format from testm import addition and this also works.

Code sharing

I know the topic of code sharing has been raised by @dhylands in #187 but in the light of this bug I would like to raise it here too. It doesn't make sense to me that importing works in the unix port but not the stm port. This should be common functionality that works identically (or doesn't) in all ports using shared code.

I've made it clear before that my knowledge of C is just enough to be dangerous so take what I say with a pinch of salt. In Java one would naturally make use of inheritance to deal with this issue. My 5 minutes of browsing showed me it isn't quite so easy in C but there does seem to be ways of dealing with this problem:

http://stackoverflow.com/questions/415452/object-orientation-in-c/415536#415536

This is my 2c worth and I will leave it up to the C gurus to come up with something more robust than we currently have.

It seems this Laurent Deniau chap is quite the guru in writing object oriented C code:

Object Oriented Programming in C

Chapter 4 (Inheritance — Code Reuse and Refinement) of his ?1993? book Object-Oriented Programming With ANSI-C seems to be just the thing we need. I'll read it and see whether I can figure out what he is on about.

His more recent work seems to be pushing towards creating an entire object oriented framework for C which is probably a bit of an overkill for us:

Overview of the C Object System ∗
Using C as an high-level object-oriented language

But the rest of you probably knew all this already?

@royemmerich: There's misunderstanding, import didn't work for STM not because it has different implementation if import comparing to Unix port, but because it had filesystem semantics differences from a normal POSIX filesystem. Specifically:

1. STM fatfs doesn't support long filenames - which is strange, because underlying fatfs drivers has support for them. I assume it's the matter of right configuration of the driver.
2. It apparently doesn't support notion of "current directory". Which alone makes complicated to support exact Python module load semantics. (This is worked around by providing specific (literally, hardcoded) directories where user source should reside; arbitrary dirs for user code require explicit, albeit simple, configuration of sys.path).
3. As it turned out, not just notion of "current dir" not supported, but relative paths at all, which made default fallback behavior of import not work as expected.

Per patch and comments above, search path issue is now resolved. So, let's close this ticket. Feel free to open separate tickets for other issues uncovered (like no support for long filenames on FS level).

Some correction: support for current dir, etc. is subject to configuration of fatfs, more info: http://elm-chan.org/fsw/ff/en/filename.html

Long filenames support was posted in #316.