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, markgrandi, ned.deily, r.david.murray, ronaldoussoren, serhiy.storchaka
Date 2013-06-11.08:40:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1370940058.74.0.601421245448.issue14455@psf.upfronthosting.co.za>
In-reply-to
Content
The fifth version of the patch should be much cleaner.

Changes:

* Coding style cleanup, the new code uses PEP8 conformant names for
  methods and variables.

* Explicitly make private classes private by prefixing their name with
  an underscore (including the old XML parser/generator classes)

* Remove support in the binary plist code for sets and uuids, neither can
  be written to plist files by Apple's code.

* More tests

* There is no support for JSON because JSON is not supported by Apple's
  propertylist APIs either. The command-line tool plutil does support
  JSON output, but the C and Objective-C APIs do not.

* There is no support for the old OpenStep format. That format is badly
  documented, has been deprecated for a long time, and writing it is 
  not supported by Apple's plist libraries.  The OpenStep format also 
  seems to be much more limited than the two modern ones.

Open issues:

* The patch contains plistlib.{dump,dumps,load,loads} which mirror the
  functions with same name from the pickle and json modules. 

  Is is usefull to add those functions to plistlib, and deprecate the 
  older functions?

  Advantages:
  + Cleaner API
  + Provides a clean path to remove plistlib.Data and 
    plistlib._InternalDict (the latter is already deprecated)

  Disadvantages:
  - Very (too?) close to needless code churn

* Is renaming PlistParser and PlistWriter ok? Both are private and a 
  quick search on google seems to indicate that nobody directory uses
  these classes.

  If renaming is ok, should methods/variables be renamed to PEP8 style?

* Should a 'default' keyword be added to the serialization functions
  (simular to the keyword in json.dump)

  I don't have a usecase for this, the only reason to add is is 
  consistency with the json module

* Should a 'skipvalues' keyword be added to the serialization functions
  (to ignore values that cannot be serialized, see #11101)

  I'm not convinced that this would be a good idea.

* Should a 'check_circular' keyword be added to the 
  serialization functions (again similar to the same keyword for
  json.dump)? 

  This would avoid relying on the recursion limit to break infinite loops
  when serializing circular datastructures.

  Would need to check if binary plist can contain circular data structures
  when they are written using Apple's libraries.
History
Date User Action Args
2013-06-11 08:40:59ronaldoussorensetrecipients: + ronaldoussoren, ned.deily, eric.araujo, r.david.murray, jrjsmrtn, serhiy.storchaka, d9pouces, markgrandi
2013-06-11 08:40:58ronaldoussorensetmessageid: <1370940058.74.0.601421245448.issue14455@psf.upfronthosting.co.za>
2013-06-11 08:40:58ronaldoussorenlinkissue14455 messages
2013-06-11 08:40:51ronaldoussorencreate