This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ronaldoussoren
Recipients d9pouces, eric.araujo, jrjsmrtn, ned.deily, r.david.murray, ronaldoussoren, serhiy.storchaka
Date 2012-04-06.16:44:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333730657.7.0.902097712736.issue14455@psf.upfronthosting.co.za>
In-reply-to
Content
I (as one of the Mac maintainers) like the new functionality, but would like to see some changes:

1) as others have noted it is odd that binary and json plists can be read but not written

2) there need to be tests, and I'd add two or even three set of tests:

   a. tests that read pre-generated files in the various formats
      (tests that we're compatible with the format generated by Apple)

   b. tests that use Apple tools to generated plists in various formats,
      and check that the library can read them
      (these tests would be skipped on platforms other than OSX)

   c. if there are read and write functions: check that the writer
      generates files that can be read back in.

3) there is a new public function for reading binary plist files, 
   I'd keep that private and add a "format" argument to readPlist
   when there is a need for forcing the usage of a specific format
   (and to mirror the (currently hypothetical) format argument for
   writePlist).

Don't worry about rearchitecturing plistlib, it might need work in that regard but that need not be part of this issue and makes it harder to review the changes. I'm also far from convinced that a redesign of the code is needed.
History
Date User Action Args
2012-04-06 16:44:17ronaldoussorensetrecipients: + ronaldoussoren, ned.deily, eric.araujo, r.david.murray, jrjsmrtn, serhiy.storchaka, d9pouces
2012-04-06 16:44:17ronaldoussorensetmessageid: <1333730657.7.0.902097712736.issue14455@psf.upfronthosting.co.za>
2012-04-06 16:44:17ronaldoussorenlinkissue14455 messages
2012-04-06 16:44:16ronaldoussorencreate