We only define 'round3' for PY2 and 'round2' for PY3, and also make sure 'round3' is always an alias of
the built-in 'round' on Python 3; and similarly 'round2' is an alias of built-in 'round' on Python 2.
Thus, for clarity, one can do:
from fontTools.misc.py23 import round3 as round
or
from fontTools.misc.py23 import round2 as round
and be certain that the fast built-in implementation will be used on the
respective python major version.
When one does `from fontTools.misc.py23 import *`, everything seems to work fine.
However, linters will complain when one uses the asterisk to import all names from a module, since they can't detect when names are left undefined -- asterisks are greedy and will eat all names.
If one avoids the asterik and attempts to import explicitly, like in `from fontTools.misc.py23 import basestring`, the problem then is that, if `py23` does not re-define the name -- e.g. under python2 `basestring` or `unicode` are built-ins -- then the import statement raises `ImportError`.
The same happens for the `unichr` function on a "wide" Python 2 build (in which `sys.maxunicode == 0x10FFFF`).
Now, to work around this, we need to re-assign those built-ins to their very same names. This may look silly, but at least it works.
Part of https://github.com/behdad/fonttools/issues/236
Now we fallback to ASCII for unknown encodings. Not sure if this might be a bad idea.
The main user-visible difference is that if there's an ASCII-only text in an unknown
encoding, we still "decode" it and use unicode="True" instead of unicode="False".
Or is assuming that any unsupported encoding is ASCII-compatible too intrusive?
misc.psLib tries to subclass StringIO. It doesn't work with
the cStringIO version.
Change doesn't seem to affect performance of CFF, which is the
biggest StringIO user.
7279302238 (commitcomment-4767054)
