Currently json.dump and json.load only take “a .read/write()-supporting file-like object containing a JSON document”. Since pathlib.Path has the write_text and read_text functions we should be able to leverage it for the JSON file serialization and deserialization without having to call open on it. Currently if I have a pathlib.Path object I need to do:
with open(my_path) as f:
my_object = json.load(f)
or:
my_object = json.loads(my_path.read_text())
but it would make sense to have the ability to do:
I disagree. They take file-like objects, not path-like objects. If something takes a Path I also want it to take a str that points to a file, but I don’t want that here.
But then, I’ve never noticed or used the read_text/write_text methods, and I’m surprised those exist…
You could always use
my_object = json.load(my_path.open())
Is saving 7 characters worth a more confusing interface?
I’d favor a distinct function for this, e.g. json.load_path.
It keeps the interfaces clear in the same way that load vs loads does.
You should probably be reading JSON data as bytes, and loads(path.read_bytes()) is less efficient than passing a file handle, since the entire file must be read into Python bytes before parsing.[1]
Overall I’m +0 on this. It would be mildly useful occasionally, and if it’s a separate function there are relatively few harms.
I’d move to -1 if changes were proposed to other parts of json, e.g., JSONDecoder. Downstream libraries would then be negatively impacted.
I have always assumed that the parser iterates through chunks of the file. Feel free to correct me if I’m wrong. ↩︎
I used to assume that too, until I checked the source code to confirm. The implementation of json.load() just calls json.loads(fp.read()). There’s absolutely no difference. That may not be true of dump/dumps though, as it uses an iterator and writes each chunk as it gets it.
This is a recurring idea, proposed every year. Search for previous discussions.
The main objectives:
json.load() and json.dump() are not just random functions, they are modelled oafter similar functions in other modules. If we add new functions in json, we will be forced to add similar new functions in pickle, marshal, plistlib and third party modules like yaml. This change has larger cost that you anticipated.
Reading JSON from an uncompressed file on disk is just not so common special case. Today, reading JSON from a socket or HTTP stream, or compressed file, or archive may be more common. You already can do this in two lines instead of one line, and you can add a simple helper function in your program if this is a common operation in your code.