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.
in version 0.6.4 (installed on OS X 10.10 python lib/extras) it raises
KeyError, whereas in the latest version available fom PyPI (v0.7.8) it
raises IOError.
Fixes issue in https://github.com/googlei18n/nototools/issues/113
PSTokenizer is now an indipendent object behaving like a StringIO.StringIO: it has `read` and `close` methods, as well as `buf`, `pos` and `len` attributes.
The input data is a string of bytes, and the output tokens are ascii-decoded unicode strings.
(I removed "__main__" as it was using a non-py23 EasyDialogs module)
See https://github.com/behdad/fonttools/issues/393.
Related to https://github.com/behdad/fonttools/issues/391.
This should make the unit tests more readable, and it also prevents
failures where a changed fromXML() implementation fails to ignore
interspersed whitespace. This has recently caused some developer
nuisance; see https://github.com/behdad/fonttools/pull/367.
Instead of having a custom parser implementation, it would be nicer
to call the actual XMLReader. However, XMLReader has a deeply built-in
assumption that it is processing an entire TTX file. Changing this
assumption would certainly be possible, but it would need a re-write
of the XMLReader code; having a custom parser just for unit tests
seems less involved.
If no "encoding" argument is provided to Python3 `open`, the default plaftorm's encoding (cp1252 on Windows) is used when decoding bytes to unicode strings.
So, we use the `io.open` function (i.e. a backport of Python3 default file interface) with `encoding="utf_8"` argument.
Fixes https://github.com/behdad/fonttools/issues/323
