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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2FRLNZDC3EUEARCGKAWDCWC66V24L4YK/
Code of Conduct: http://python.org/psf/codeofconduct/