Second, the resulting function would have monstrous interface. open()
takes 8 arguments,
well, maybe not -- this would not need to support the entire open() interface:
* No one is suggesting getting rid of the current load() function, so if you need to do something less common, you can always open the file yourself.
* Many of the options to open() should be always the same when reading/writing json. In fact, that's (IMHO) the most compelling reason to have this built in -- the defaults may be not ideal for JSON, and other specs may be downright wrong. Here they are all eight parameters.
mode='r' : this should be either 'r' or 'w' depending on loading or saving, I don't think there's any other (certainly not common) use case for any other mode.
buffering=-1 : This seems very reasonable to put in control of the JSON encoder/decoder
encoding=None: this is the important one -- json is always UTF-8 yes?
errors=None: This also is good ot be in control of the JSON encoder/decoding
newline=None: also in control of the encoder
closefd=True: I think this is irrelevant to this use case.
opener=None: Also does not need to be supported
If I have this right, then none of the optional arguments to open() would need to be passed through.
> they should be combined. And thank that open() does not accept arbitrary
var-keyword arguments as json.load(), resolving this conflict would be
impossible.
see above -- there is no conflict to resolve.
Third, this combination is not so common as you think.
agreed -- but still fairly common. And most of the use cases that aren't file-on-disk are strings anyway. I know I use file-on-disk most of the time I use .load()/dump(), even if I use .loads()/dumps() more frequently.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython