Fix Backwards Logic of 'wait_for_response' In #3005 #3006
Conversation
| @@ -127,7 +127,7 @@ def reset(self): | |||
| self.write(b"\r" + REPL.CHAR_CTRL_B) # enter or reset friendly repl | |||
| data = self.read_until(b">>> ") | |||
|
|
|||
| def execute(self, code, timeout=10, wait_for_response=False): | |||
| def execute(self, code, timeout=10, wait_for_response=True): | |||
There was a problem hiding this comment.
Thanks. It might be a bit better to def execute(self, code, timeout=10, *, wait_for_response=True): so that any old code that called execute(code, timeout, True) intending to get async behvior will be a runtime error, instead of turning into a call with wait_for_response=True. If the only users are in the circuitpython source tree, though, this scarcely matters.
There was a problem hiding this comment.
This is a very excellent point, and I don't consider it a nit-pick at all.
I don't expect many people are using this. I point to it as an example how to interact with boards via a PC, but that's about it.
A lot of the semantics are so that it remains py2/py3 compatible, from what I understand (its base is MicroPython's tools/pyboard.py). I'll likely give it more scrubs for a multitude of reasons. One of those scrubs will include removing Python2 use; not worth using at this point.
|
I'm actually going to go ahead and merge this. No reason to leave it open, as I won't get to removing Python2 support for while. |
See #3005 (comment)