Agree. There needs to be a way of doing this in a portable way (that works on unix and stm, for example). That means stm needs to define a sys.stdout object. Probably the best thing to do is provide file descriptors in the stm port with 0,1,2 mapping to std in,out,err as usual. Then the same file code (currently in unix/) can be used.

file descriptors in the stm port with 0,1,2 mapping to std in,out,err as usual.

From Python perspective, no need to use to mimic it down to numbers. Just an object which implements read/write C-level protocol, it can wrap FIL* or some serial object just as well.

Then the same file code (currently in unix/) can be used.
Well, good deal of the code is actually in py/stream.c . With that, and taking unix/file.c, it can be implemented without any double indirection (but with some duplication, but that can be refactored too).

All in all, there's known workaround - just don't mix print() and sys.write(), and good fix will require some thinking (one thought is that ->print() should be provided with both stream interface for efficient out, and printf interface for convenience).

So, this is more of "known issue", not something to work on right away (IMHO).

Resolved.