On Fri, Sep 18, 2020 at 1:05 PM Christopher Barker <pythonchb@gmail.com> wrote:
> I see the issue here, but isn't that inherent in duck typing? It's not specific to overloading. In fact the current implementation of json.load() simply calls the .read() in the object passed in. If it does not have a read method, you get an AttributeError. IF someone where to pass in a string subclass with a read method, and that method returned the right thing, it would "just work". Here's an example:
>
Yes - it would indeed just work, and that's because the function
*name* specifies whether it's going to read from a file object or open
a path name. There's no ambiguity; if you call load() on something
that's both a path and a file, it'll work, and if you call loadf() on
something that's both a path and a file, it'll also just work. But if
you try to make those into one and the same function, how's it going
to pick from the two options?
We can certainly document that it tries to use it as a path first. I suppose you could catch the FileNotFoundError and then try to use it as a file-like object.
I understand the theory here: but practicality beats purity -- do we really imagine that folks will create these path-like and file-like objects, and then pass them into json.load() and get upset when it behaves oddly?
And this really doesn't feel that different from the fact that you can create an object with a .read() method that does something different, and it will fail then, too.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython