micropython-lib/python-stdlib/json references re.VERBOSE etc.

[swork]

At least in rp2 port (AFAICT) micropython/lib/re1.5 doesn't honor or even define CPython's flags constants (like re.VERBOSE, re.MULTILINE, and short synonyms re.X, re.M, etc.), but micropython-lib/python-stdlib/json references these constants and thus won't import.

micropython/extmod/modjson.c implements dump/s and load/s without using re, so it works fine within its limits. Did the big non-U rename miss the need to remove micropython-lib/python-stdlib/json altogether, or is it still used in other contexts?

I burned some time thinking "mip install json" was a required step (since something called "json" exists in micropython-lib). Freezing the micropython-lib json also shadows modjson.c. Would others be helped by removing json from micropython-lib/python-stdlib?

[jimmo]

@swork I think the problem is that when I split up micropython-lib it missed that json requires the ffi-based re implementation. So yes, your suggestion is correct, we should move json into the unix-ffi directory instead of python-stdlib.

See micropython/micropython-lib#809

Some history: large parts of the original micropython-lib were implemented by a previous maintainer who had more of a focus on supporting these features on the unix port of micropython, and so many of the libraries are implemented in terms of FFI to system libraries (i.e. re uses PCRE). All the packages were in a flat directory and it wasn't immediately clear how to tell whether a given package would work on embedded ports.

I've been trying to extract out the parts of micropython-lib so it's primarily useful for the embedded use case, and putting all the unix-only FFI packages into their own "namespace" so that the general-purpose packages don't accidentally depend on them. Looks like I missed this detail in json.