Re-use of standard library across implementations

alanjds · September 12, 2019, 8:20pm

Thank you for positioning about this subject.

My plan is to use _pycodecs.py in Grumpy, propose it to be used on RustPython and look for others and their interest (Micropython and Transcrypt to start).

Micropython for example support only utf-8, is not extensible and have codecs.py as a dummy. Having codecs.py importable in this environment would fix some issues on their side.

In fact, I already started hacking a _pycodecs.py.

Side question:

github.com

python/cpython/blob/main/Lib/codecs.py#L83


      
          
          # Old broken names (don't use in new code)
          BOM32_LE = BOM_UTF16_LE
          BOM32_BE = BOM_UTF16_BE
          BOM64_LE = BOM_UTF32_LE
          BOM64_BE = BOM_UTF32_BE
          
          
          ### Codec base classes (defining the API)
          
          class CodecInfo(tuple):
              """Codec details when looking up the codec registry"""
          
              # Private API to allow Python 3.4 to denylist the known non-Unicode
              # codecs in the standard library. A more general mechanism to
              # reliably distinguish test encodings from other codecs will hopefully
              # be defined for Python 3.5
              #
              # See http://bugs.python.org/issue19619
              _is_text_encoding = True # Assume codecs are text encodings by default

Is there a performance reason for this to be a tuple or I can replace with a bare old object to simplify some code? Assuming backwards compatibility and tests passing, of course.