You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bytes objects lack a decode method in smaller non-Express builds #384
The decode method for converting from bytes to str is missing in non-Express builds. This makes it awkward to take data from I/O and print it. It seems like this should exist, obviously the codec is ignored on a microcontroller but being able to switch immutable data types from one that iterates as ints to one that is printable and iterates as one character strings is desirable. Depending on the micropython gc internals both could share the same data buffer behind the scenes (I haven't looked inside that box yet...).
Workaround, a silly looking: ''.join(chr(b) for b in bytes_data)
Noticed when using the Feather M0 Basic 2.1.0 circuitpython release. I had to work around this when moving code over from where I developed it on an Express.
But from that comment, wouldn't just str(my_bytes, 'utf-8') and bytes(my_string, 'utf-8') work in place of my_bytes.decode('utf-8') and my_string.encode('utf-8')?
Turning on MICROPY_CPYTHON_COMPAT costs 792 bytes. Right now we have 3912 bytes free in the Gemma build (for example). But we are looking to add framebuf, and we don't know the storage budget needed for 3.0 yet.
@gpshead: is str(some_bytes, 'ascii') ok for you as a workaround?
(Note that str(b'abc') returns "b'abc'": you need the second argument to get 'abc'. However, the value of the second argument is actually ignored right now: no decoding is done.)
I wonder if it would make sense to actually disableMICROPY_CPYTHON_COMPAT in the large build, so as to avoid code that only works on some platforms for no reason.
As for disabling in the larger build... I'm in favor of that when reasonable workarounds exist (as in this case). The fewer behavior differences between different circuitpython builds the better; though I could just as easily argue the other way with regards to being compatible with Micropython on larger microcontrollers.
I think we should disable this for consistency across atmel-samd, esp8266, and nrf builds, as suggested by @deshipuabove. The features added by MICROPY_CPYTHON_COMPAT encompass a bunch of different things, and should be broken down into separate flags: there's even a comment to that effect in py/mpconfig.h. We can wait for MicroPython to do that. If no comments I will go ahead and disable it in all CPy builds.
Activity
tannewt commentedon Oct 31, 2017
This should be as easy as enabling a define in mpconfigport.h
deshipu commentedon Oct 31, 2017
The flag for this is
MICROPY_CPYTHON_COMPAT, but the comment next to it says:tannewt commentedon Oct 31, 2017
@dhalbert I think this is a good candidate for using some of the space you freed. What do you think?
Anyone know what the code size cost of enabling this is?
deshipu commentedon Oct 31, 2017
But from that comment, wouldn't just
str(my_bytes, 'utf-8')andbytes(my_string, 'utf-8')work in place ofmy_bytes.decode('utf-8')andmy_string.encode('utf-8')?dhalbert commentedon Oct 31, 2017
Turning on
MICROPY_CPYTHON_COMPATcosts 792 bytes. Right now we have 3912 bytes free in the Gemma build (for example). But we are looking to addframebuf, and we don't know the storage budget needed for 3.0 yet.@gpshead: is
str(some_bytes, 'ascii')ok for you as a workaround?(Note that
str(b'abc')returns"b'abc'": you need the second argument to get'abc'. However, the value of the second argument is actually ignored right now: no decoding is done.)deshipu commentedon Oct 31, 2017
I wonder if it would make sense to actually disable
MICROPY_CPYTHON_COMPATin the large build, so as to avoid code that only works on some platforms for no reason.gpshead commentedon Nov 3, 2017
Workaround
str(binary_data, 'ascii')works. Thanks!As for disabling in the larger build... I'm in favor of that when reasonable workarounds exist (as in this case). The fewer behavior differences between different circuitpython builds the better; though I could just as easily argue the other way with regards to being compatible with Micropython on larger microcontrollers.
dhalbert commentedon Jan 9, 2018
I think we should disable this for consistency across atmel-samd, esp8266, and nrf builds, as suggested by @deshipu above. The features added by
MICROPY_CPYTHON_COMPATencompass a bunch of different things, and should be broken down into separate flags: there's even a comment to that effect inpy/mpconfig.h. We can wait for MicroPython to do that. If no comments I will go ahead and disable it in all CPy builds.