There's a small amount of overhead to overloading:
- 2x conditionals
- 1x function call overhead (additional stack frame)
Instead of this approach we could either
- inline the existing contents of _load by indenting within the conditional
- just add the new code at the top of the function
- use multiple dispatch
```python
import os
import json
import pathlib
def test_load(n):
print(('n', n, load))
with open('test.json','w') as f:
json.dump(True, f)
assert load('test.json')
assert load(pathlib.Path('test.json'))
with open('test.json', 'r') as f:
assert load(f)
def _load(file_, **kwargs):
# ... rename existing json.load to json._load ...
print(('load', file_, kwargs))
return True
def load(file_, *, encoding="UTF-8", **kwargs):
if isinstance(file_, str) or hasattr(file_, "__fspath__"):
with open(os.fspath(file_), "r", encoding=encoding) as f:
return _load(f, **kwargs)
else:
return _load(file_, **kwargs)
test_load(1)
def load(file_, *, encoding="UTF-8", **kwargs):
if isinstance(file_, str) or hasattr(file_, "__fspath__"):
with open(os.fspath(file_), "r", encoding=encoding) as f:
return _load(f, **kwargs)
return _load(file_, **kwargs) # (or inline the existing json.load)
test_load(2)
## singledispatch
#
https://docs.python.org/3/library/functools.html?highlight=dispatch#functool...
from functools import singledispatch
@singledispatch
def load(file_, **kwargs):
return _load(file_, **kwargs)
@load.register(str)
def load_str(file_: str, *, encoding='UTF-8', **kwargs):
with open(file_, "r", encoding=encoding) as f:
return _load(f, **kwargs)
@load.register(os.PathLike)
def load_pathlike(file_: os.PathLike, *, encoding='UTF-8', **kwargs):
with open(os.fspath(file_), "r", encoding=encoding) as f:
return _load(f, **kwargs)
test_load(3)
```
On Thu, Sep 17, 2020 at 10:08 PM Inada Naoki
On Fri, Sep 18, 2020 at 12:07 AM Paolo Lammens
wrote: Besides, I don't understand what the downside of overloading is, apart
from purism (?).
I am one of who are conservative about overloading. I agree this is purism, but I want to explain behind of this purism.
In statically, and nominal typed language, overloading is simple and clear because only one type is chosen by compiler. On the other hand, compiler or VM can not choose single type in duck-typed (or structural typed) languages.
For example,
* str subtype can implement read/write method. It is both of PathLike and file-like. * File subtype can implement `.__fspath__`. It is both of PathLike and File.
Of course, statically typed languages like Java allow implementing multiple interfaces. But Java programmer must choose one interface explicitly when it is ambiguous. So it is explicit what type is used in overloading.
On the other hand, in case of Python, there are no compiler/VM support for overloading, because Python is duck-typed language.
* `load(f, ...)` uses `f.read()` * `dump(f, ...)` uses `f.write()` * `loadf(path, ..)` and `dumpf(path, ...)` uses `open(path, ...)`
This is so natural design for duck-typed language.
Regards, -- Inada Naoki
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/ZZOHJI... Code of Conduct: http://python.org/psf/codeofconduct/