When writing unit tests for XML data, it is more convenient to compare
list of lines, instead of a single string without newlines.
This helps identifying which lines in the diff printed on the console
don't match the expected result.
So, getXML now returns a list of lines,
To allow passing the same list of lines to the complementary parseXML
function in the roundtrip tests, parseXML now also accepts a list of
strings, as well as a single string.
We also use unicode_literals, and ensure that if the test modules passes
unicode str, we first encode to UTF-8 before passing on to expat XML
parser. This is because on Python 2, expat only accepts bytes strings.
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.
By default (newlinestr=None), the XMLWriter will still use the `os.linesep` as the
newline string.
Otherwise, it will use the specified `newlinestr`.
This is useful when TTX files under version control are being written from
multiple platforms; in which case, one usually wants to always use one
specific line ending (most likely LF, which is what the XML spec itself
normalizes it to).
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...)
