I agree, but recording the history will do a lot of write cycles on the flash. It is maybe not an issue when using a sd card, as you can change it, but what about the internal flash? How many write cycle can it handle?

This feature should be an option the user has to specifically turn on, knowing the risks.

For other features, like code completion, I guess this would use a lot of memory...

Ohh,
did not know about that. Or my terminal (screen under Linux) is not sending the right ANSI escapes.

Need to test.

History could be cached in (user adjustable) RAM. Only if you want to make it persistent, a write down could be issued for every n new commands. That should lower the write cycles quite a bit.

Yep, completion would be quite resource hungry. And since you normally do not deal with very large and complex modules like pylab on the pyboard, completion might not really be so helpful.

Another idea would be to hack ipython on the PC side to work with the pyboard. Instead of sending the commands to an local python-interpreter it would send them over serial to the pyboard. Does ipython have the ability to e.g. execute the commands on another machine?
There was something like clustering with the ipython webinterface. Would be fun to use the ipython notebook webinterface to test and debug the pyboard.

The '>' is implemented within do_cat and do_echo - I guess this should be done in a more generic way by building it into Shell.line_to_arg(line).
'micropython' is implemented using exec() - and seems to be working fine.