On Sat, Sep 12, 2020 at 1:40 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
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