This should be as easy as enabling a define in mpconfigport.h

The flag for this is MICROPY_CPYTHON_COMPAT, but the comment next to it says:

// These methods are superfluous in the presence of str() and bytes()
// constructors.

@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?

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 disable MICROPY_CPYTHON_COMPAT in the large build, so as to avoid code that only works on some platforms for no reason.

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.

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_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.