The glyph coordinates in glyf table are going to be rounded when
writing out, so we should use the same mode of conversion to
integers. Otherwise the xMin of a glyph might end up being
different from its actual minimum X.
It seems like sets are hashed differently in CPython and PyPy.
Because of this, the returned list of class sets may have a different sort
order (within each class size) between the two implementations.
For now, I make the test pass on both CPython and PyPy by casting the returned
list of sets into a set of (frozen) sets, and asserting that its *content* is
correct, without considering the *order* of the sets in the list.
set objects have different __repr__ on python 2 and 3
Python 3:
>>> {1, 2, 3}
{1, 2, 3}
Python 2
>>> {1, 2, 3}
set([1, 2, 3])
(one among the several reasons I don't particularly like doctest...)
Since py23 modifies some essential builtins, it's safe to import
everything all the time. At least, that's how it was designed.
It's a bug if importing * breaks some code.
Apparently I need to do that, or the child python process does not see fontTools in the path.
Another workaround woud be to ensure that fontTools is installed, at least in editable or develop mode (via `pip install -e .`). But the way we temporarily extend the PYTHONPATH in run-test.sh is less intrusive.
Both _StderrHandler and Logger.callHandlers included here are taken from Python 3.5's
logging.py source.
I only set logging.lastResort if it's not already set (i.e. for Python < 3.2).
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
