incorrect integer representation with python2

[Hans-Christoph Steiner]

Using biplist 1.0.1 with python XXX on i386, one of the tests fail:

======================================================================
FAIL: testIntBoundaries (test_write.TestWritePlist)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/.pybuild/pythonX.Y_2.7/build/tests/test_write.py", line 272, in testIntBoundaries
    self.roundTrip(cases)
  File "/<<PKGBUILDDIR>>/.pybuild/pythonX.Y_2.7/build/tests/test_write.py", line 41, in roundTrip
    self.assertEqual(repr(case if expected is None else expected), repr(readResult))
AssertionError: '[4294967295L, 4294967294L, 4294967296L, 4294967293L, 4294967297L, 8589934590L, 2147483647L]' != \
                         '[4294967295L, 4294967294L, 4294967296L, 4294967293L, 4294967297L, 8589934590L, 2147483647]'

from: https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=860656

You'll see that the final value gets converted to an int instead of remaining as a long. Since the plist format stores the length of the integer, storing a long should always return a long:

<integer> 0001 nnnn # of bytes is 2^nnnn, big-endian bytes

On python3 this does not matter, since there is no long type, only int.

[Stefano Rivera]

I don't think that it really is expected that the python type correctly round-trips through a plist. I can see that the plist writer chooses an int size that is big enough to represent the value provided, it does not care what type it was.

https://bitbucket.org/wooster/biplist/src/d9dccdee02e302ced112f4056452eca20949fcf6/biplist/init.py?at=master&fileviewer=file-view-default#init.py-851

So, ignoring the disparity of python types in the assertion is probably the correct thing to do.

[Hans-Christoph Steiner]

I think it makes sense to do what Apple's writer is doing, to keep things consistent.

Your link is 404 Not Found for me.

Stefano Rivera: