Open deshipu opened 6 years ago
Is redirecting the REPL output such as print
really the right way? Wouldn't something like basic logging
support be more like CPython? Exceptions could be caught and logged then.
There are many ways to do it, but since we already have the mechanism for this in place (only in one port, but it's there), and this gives us the most possibilities (like the WebREPL, or ability to use the REPL directly on a device that has a keyboard connected), it made the most sense to me. It also lets you do simple debugging with prints without having to teach users to use a logging framework. It seems it's the simplest thing that could possibly work.
I'm open to this but don't want to add the work to 3.0. Lets consider it for 4.0 after 3.0 is ready.
I am currently looking at using CircuitPython with WiFi as a mobile robot controller. I already have code that will update from a web server on my laptop on boot, so the ability to debug over WiFi as well would make it perfect.
When we build projects using the CircuitPython boards, we will often connect to them output devices, such as character displays, LCDs, OLEDs, LED matrices, thermal printers and so on. That potentially gives us the ability to display debugging output and exception traceback in a more convenient way, without having to connect to the computer to see the serial communications. We just need some way to plug our own function into the REPL output.
As far as I know, the ESP8266 has that capability, as it was necessary for implementing the WebREPL. However, it seems to be pretty much undocumented, and only constrained to that one port.
It would be nice to have the
multiterminal
module implemented across ports, in a less socket-specific way, and documented.