On Tue, Sep 15, 2020 at 5:26 PM Wes Turner <wes.tur...@gmail.com> wrote:
> On Tue, Sep 15, 2020 at 9:09 AM Wes Turner <wes.tur...@gmail.com> wrote: > >> json.load and json.dump already default to UTF8 and already have >>> parameters for json loading and dumping. >>> >> so it turns out that loads(), which optionally takes a bytes or bytesarray object tries to determine whether the encoding is UTF-6, UTF-!6 or utf-32 (the ones allowed by the standard) (thanks Guido for the pointer). And load() calls loads(), so it should work with binary mode files as well. Currently, dump() simply uses the fp passed in, and it doesn't support binary files, so it'll use the encoding the user set (or the default, if not set, which is an issue here) dumps() returns a string, so no encoding there. I think dumpf() should use UTF-8, and that's it. If anyone really wants something else, they can get it by providing an open text file object. loads(), on the other hand, is a bit tricky -- it could allow only UTF-8, but it seems it would be more consistent (and easy to do) to open the file in binary mode and use the existing code to determine the encoding. -CHB >> The Python JSON implementation should support the full JSON spec (including UTF-8, UTF-16, and UTF-32) and should default to UTF-8. 'turns out it does already, and no one is suggesting changing that. Anyway -- if anyone wants to push for overloading .load()/dump(), rather >> than making two new loadf() and dumpf() functions, then speak now -- that >> will take more discussion, and maybe a PEP. >> > > I don't see why one or the other would need a PEP so long as the new > functionality is backward-compatible? > iIm just putting my finger in the wind. no need for a PEP if it's simeel and non-controversial, but if even the few folks on this thread don't agree on the API we want, then it's maybe too controversial -- so either more discussion, to come to consensus, or a PEP. Or not -- we can see what the core devs say if/when someone does a bpo / PR. -CHB > > >> -CHB >> >> >> >> -- >> Christopher Barker, PhD >> >> Python Language Consulting >> - Teaching >> - Scientific Software Development >> - Desktop GUI and Web Development >> - wxPython, numpy, scipy, Cython >> > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2BOVZAJAC7X3PBWNGAYUGBTVGZBVEZW5/ Code of Conduct: http://python.org/psf/codeofconduct/
