To reproduce:
import plistlib
print plistlib.writePlistToString([[[[[[[[[{'test': plistlib.Data('aaaaaa')}]]]]]]]]])

Compare to:
print plistlib.writePlistToString([[[[[[[[{'test': Data('aaaaaa')}]]]]]]]])

It looks like the max line length calculation in the Data class is causing the output to be empty once you get nested far enough.

My second print should have been:

print plistlib.writePlistToString([[[[[[[[{'test': plistlib.Data('aaaaaa')}]]]]]]]])

Quick source inspection suggests this is present in the latest version.

We should limit the indentation to be less than the maximal line length.

Looks like plistlib.writePlistToString is no loger in the plistlib.

On 3.x it's called writePlistToBytes, and it seems to have the same issue.

Yep you are correct.
>>>
plistlib.readPlistFromBytes(plistlib.writePlistToBytes([[[[[[[[{'test': plistlib.Data(b'aaaaaa')}]]]]]]]]))
[[[[[[[[{'test': Data(b'aaaaaa')}]]]]]]]]
>>> plistlib.readPlistFromBytes(plistlib.writePlistToBytes([[[[[[[[[{'test': plistlib.Data(b'aaaaaa')}]]]]]]]]]))
[[[[[[[[[{'test': Data(b'')}]]]]]]]]]

I presume we want to raise a ValueError if the indentation is more than the maximal line length.

If possible it would be better to still generate a valid output, possibly by limiting the indentation or removing it after a certain point.
However I don't know if there are any restrictions that should be followed while generating a plist (What happens if the line is too long? Is the indentation required?).

I agree that plistlib shouldn't raise an exception for data that can represented as a valid plist file.

I've checked that the Cocoa class for generating plist files will happily create a plist file when the data is nested 100 levels deep. In that case NSData values generate lines of 12 characters long.



An unrelated issue: PlistWriter.writeValue should treat bytes instances the same as Data instances in Python 3. That would be a (small) feature enhencement, and hence can only be done for Python 3.4.

The attach patch should fix the issue (but there needs to be a unittest as well).

Adding tests.

The tests look good, thanks for writing them.

New changeset a389700fbc74 by Ronald Oussoren in branch '2.7':
Ensure that plistlib doesn't corrupt deeply nested datastructures
http://hg.python.org/cpython/rev/a389700fbc74

New changeset 6a8cb4875ac6 by Ronald Oussoren in branch '3.3':
Ensure that plistlib doesn't corrupt deeply nested datastructures
http://hg.python.org/cpython/rev/6a8cb4875ac6

New changeset e0c0bcd60033 by Ronald Oussoren in branch 'default':
(3.3->default) Ensure that plistlib doesn't corrupt deeply nested datastructures
http://hg.python.org/cpython/rev/e0c0bcd60033