Do you also want to enable
#define MICROPY_ENABLE_SOURCE_LINE
in the nrf build?

@jerryneedell Good idea. I didn't do any kind of comprehensive look at what's different in nrf. If you know of anything else let me know.

That is the one I usually add along with uncommenting out the BLE_MODULE and UBLUEPY_MODULE but I think Kevin wants this tested more before they are mainstreamed. I have been playing with them a little but happy to deal with them myself for now.

Do the workarounds for CPython compat still work in CPython? I don't want us teaching bad habits that break when moving to CPython.

@jerryneedell I'm hoping to put in a PR this week with BLE support enabled out of the box, but we migrated to a different version of the SD so I need to make sure there aren't any gotchas or breaking changes that aren't immediately visible.

@microbuilder Thanks. So far, I have tried enabling BLE with the current version and executed the ubluepy_scan and the ubluepy_eddystone examples.

I added the 2 proposed changes to the feather52 mpconfigport.h ( with PR #528 as well)

#define MICROPY_ENABLE_SOURCE_LINE (1)
#define MICROPY_CPYTHON_COMPAT (0)

The build compiles OK and I have not seen any adverse impact.
The code size is reduced by 512 bytes.
The Source line does show up in the REPL for Exception Tracebacks - nice!

Are there specific things to try to test turning off the CPYTHON_COMPAT ?

Are there specific things to try to test turning off the CPYTHON_COMPAT ?

MICROPY_CPYTHON_COMPAT enables:

• TextIOWrapper
• namedtuple("MyTuple", ("id name")) in addition to namedtuple("MyTuple", ("id", "name")) -- parsed string in addition to sequence for tuple names
• print(f) prints <function f at 0x20001220> instead of just <function>
• str() and bytes() with encoding arg (encoding as a keyword arg is not implemented in any case)
• decode() and encode() (workaround is to use str() and bytes())
• StringIO acting more like a file (closable, otherwise the underlying string is just empty)
• someobject.__dict__
• type(someobject).__name__
• close(file_descriptor) is a little different
• __main__ refers to module that was loaded by command-line -m switch (not relevant to bare-metal ports, I think)
• delattr() available
• object.__dict__ (The actual object class)
• enumerate() can take iterable and start args

As you can see most of these are edge cases for language consistency.