Devices.py improvements#122
Conversation
|
However, both that json lib and CPython raise an exception if there is an extra null byte at the end, so I need to fix this anyway to not include the delimiter at the end of the message if I want it to be compatible with CPython not just MicroPython. |
dhouck
force-pushed
the
python-devices-improvements
branch
from
d349cba to
343f9d7
Compare
|
And those removed four characters should make it work with other (working) JSON modules, including the CPython one (not tested) and the micropython-lib/unix-ffi one if they fix |
|
idk python so i cant properly review this |
|
It is not very important until I make the PR that can turn on subscriptions and events; the chance of any of the issues except the Even then, unless someone actually uses subscriptions the issues probably wonʼt come up, and this doesnʼt make subscriptions easy to use yet, just possible. |
This way it can be used without calling str() first
Previously the DeviceBus._read_message function had bugs with consecutive empty messages (should rarely happen, but should still be handled appropriately) or with two delimeters at the end of a buffer (happens when one message ends almost at the end of the buffer and another begins at the last byte of the buffer, which should be rare but is more common with subscriptions). This refactor should be more robust, and I believe also faster but I haven't benchmarked it. In the process, make the entire function work on bytearrays instead of converting to string early; this shouldn't make a difference with the JSON being all ASCII, but can if the JSON is ever serialized in UTF-8 instead of using escape sequences.
This function is used in a couple places and this makes it clearer what the poll method means
These can be caught the same way, but can also be caught more specifically, and can carry more useful detail.
dhouck
force-pushed
the
python-devices-improvements
branch
from
343f9d7 to
01357d4
Compare
|
I added just rebased on the latest upstream, and added two more small commits. One is minor refactoring, and the other is using custom exception types instead of base I had (incorrectly, it looks like, but Iʼm not yet certain) thought the refactoring would help with the events support in the library; I kept it because I think having that factored out is still better. The custom exception types just make issues easier to deal with; this should improve things for people using the library but also make it easier to spot issues when Iʼm doing library development. |
2 participants
There is currently half-working functionality for device subscriptions and events, where devices can push data to computers instead of needing method calls. I am working on fixing that up, and in the process found some issues with the Python library.
In particular:
Device.methodsa property is just a quality of life improvement; it was already available, but only if you happened to call__str__first.DeviceBus._read_messageand the added helper functions are things I found while implementing events. I did test without any of my event changes, but they should rarely matter in the current implementation.I can read Lua well enough to tell that the Lua library seems to have the same issues, but Iʼm not sure I could fix it.