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