plistlib should handle python2 ascii bytes as strings, not data

[anthrotype]

the new ufoLib.plistlib always treats bytes as <data> and unicode as <string> (like in python 3).

However this creates problems when running under python2, where it's common to use the native str type (== bytes) to encode ASCII textual data

See adobe-type-tools/afdko#486 (comment)

We can't optimistically assume that all clients of ufoLib will be well-behaved and only pass unicode values whenever they intend to write textual data under python 2. Even the ufoLib's own validators simply check that the incoming values are instances of basestring (e.g. see fontinfo validators), which on python 2 of course includes both bytes and unicode types.

I think the best solution is to add support for the use_builtin_types option in plistlib.load/dump functions. When set to True, we get the current behavior. When set to False we get the legacy, deprecated behavior: ie. plistlib.Data (a thin wrapper around a bytes object) gets seralised to <data> elements, whereas basestring is written as <string> elements.

[anthrotype]

Also, I think the default for the new option should be different when running ufoLib under python 2 or 3.
So if the user doesn't set the option explicitly, then a python-version-specific default will be used.

That is, under python2, we set use_builtin_types=False, and under python 3 we set it to True.

[benkiel]

@anthrotype agree with all of the above

[benkiel]

And, thank you for looking to and wrangling this!