On python2.7, the fonttools py23 module registers a 'lastResort' StreamHandler
similar to the one found in python3's logging module, that always writes
to the current value `sys.stderr`.
This also applies to any python library that imports from fontTools.misc.py23
under python2.7.
The logging module has a 'shutdown' atexit handler that flushes all the
logging handlers' streams just before the python interpreter exits.
Sometimes (e.g. when calling `python setup.py test` as in MutatorMath's test
suite), the interpreter termination ends with a traceback, which is
triggered by the atexit handler failing to flush the lastResort handler's
stream, sys.stderr
AttributeError: None has no attribute 'stderr'
This is because during module teardown, the globals (in this case 'sys')
are set to None, and the order in which modules are deleted is not
guaranteed.
See 58531934a8
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)
