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#functools.singledispatch

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 <songofacandy@gmail.com> wrote:

On Fri, Sep 18, 2020 at 12:07 AM Paolo Lammens <lammenspaolo@gmail.com> 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  <songofacandy@gmail.com>
_______________________________________________
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/ZZOHJITXXEYEAW37KM6JB3HWS54TOFU6/
Code of Conduct: http://python.org/psf/codeofconduct/