- edited description
incorrect integer representation with python2
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
.
Comments (3)
-
reporter -
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.
-
reporter 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:
- Log in to comment