> * I don't like supporting 128 bit integers because Apple's public APIs
>   don't support those values. That is, the value 'kCFNumberSInt128Type'
>   is not in a public header for the OSX 10.9 SDK.

At least we should support integers from -2**63 to 2**64-1 (signed and 
unsigned 64-bit).

> * The test_int method that you introduced tests conversions to and from XML,
> and doesn't test the problem with negative values in binary plists.

Indeed.

> * I don't understand why test_int converts a value to a binary plist twice,
>   that is the 'data2 = plistlib.dumps(pl2)' bit.

I have copied this from test_bytes(). I suppose that pl2 can be int subclass. 
Agree, for now this check is redundant.

> * I don't understand your comment about the writePlistToBytes documentation,
> there was no versionchanged in the documentation.  The version changed for
> dump was wrong, that should be versionadded (and the other new functions
> should have a versionadded as well)

http://hg.python.org/cpython/file/673ca119dbd0/Doc/library/plistlib.rst#l165

> BTW. What about out-of-range integer values? Those currently raise
> struct.error, I'd prefer to raise TypeError instead because the use of the
> struct module should be an implementation detail.

Agree. Especially if OSX SDK doesn't support deserialization of integers 
larger than 64-bit. Perhaps we should add this check for XML format too. And 
document this limitation.

> And a final question: integers with '2 ** 63 <= value < 2 ** 64' (e.g.
> values that are in the range of uint64_t but not in the range of int64_t)
> can be written to a binary plist, but will be read back as a negative value
> (which is the same behavior as in Apple's code). Should we warn about this
> in the documentation?

These values should be written as 128-bit integers (token b'\x14').