homepage

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

AltStyle によって変換されたページ (->オリジナル) /