[Python-ideas] `to_file()` method for strings
ncoghlan at gmail.com
Fri Apr 1 09:44:37 EDT 2016
On 29 March 2016 at 01:44, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
> Le 28/03/2016 17:30, Chris Barker - NOAA Federal a écrit :
>>> On Mar 24, 2016, at 7:22 PM, Nick Coghlan : what if we had a JSON-based save builtin that wrote
>>> UTF-8 encoded files based on json.dump()?
>> I've been think about this for a while, but would rather have a
>> "pyson" format -- I.e. Python literals, rather than JSON. This would
>> preserve the tuple vs list and integer vs float distinction, and allow
>> more options for dictionary keys.(and sets?).
>> Granted, you'd lose the interoperability, but for the quick saving and
>> loading of data, it'd be pretty nice.
>> There is also JSON pickle:
>> Though as I understand it, it has the same security issues as pickle.
>> But could we make a not-quite-as-complete pickle-like protocol that
>> could save and load arbitrary objects, without ever running arbitrary
> If it's for quick data saving, the security is not an issue since the
> data will never comes from an attacker if you do a quick script.
"These files will never be supplied or altered by an attacker" is the
kind of assumption that has graced the world with such things as MS
Office macro viruses. That means that as Python makes more inroads
into the traditional territory of MS Excel and other spreadsheets,
ensuring we encourage a clear distinction between code (which is
always dangerous to trust) and data (which *should* be safe to read,
aside from processing capacity limits) becomes increasingly important.
If we ever did something like this, then Chris's suggestion of a
Python-specific format that can be loaded from a string via
ast.literal_eval() rather than using JSON likely makes sense , but
it would also be appropriate to revisit that idea first as a project
outside the standard library for ad hoc data persistence, before
proposing it for standard library inclusion.
 https://code.google.com/archive/p/pyon/ is a project from several
years ago aimed at that task.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas