Am 09.11.21 um 13:44 schrieb Petr Viktorin:
And for the "encoding" case: IMO, varying the return type based on an optional "encoding" argument" is a holdover from the pre-typing era, when return types were only specified in the documentation -- just like "addch" is a holdover from the days when function signatures were only described in the docs. Nowadays, I'd consider it bad API design. The @overloads are ugly but they work -- just like the API itself. IMO we shouldn't add special cases to encourage more of it.
"encoding" arguments might be the most common case, but it's certainly not limited to that. And the fact remains that however much we desire it to be different, there are loads of APIs out there, both in the standard library and in (well received and not so well received) third-party libraries that use these constructs. This is not going to change. Also, API design is always in the eye of the beholder. Personally I prefer my example foo(x=None, y) to the design of range() of using some *args/**kwargs hacks as was suggested.
I don't believe Python's users are best served by artificially limiting possible API design, especially if it causes genuine problems (as it in the case of @overload).
- Sebastian _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2FRLNZDC3EUEARCGKAWDCWC66V24L4YK/ Code of Conduct: http://python.org/psf/codeofconduct/
