Jeroen Demeyer schrieb am 05.07.2018 um 16:53: > The only case when this handling of keywords is suboptimal is when using > **kwargs. In that case, a dict must be converted to a tuple. It looks hard > to me to support efficiently both the case of fixed keyword arguments > (f(foo=x)) and a keyword dict (f(**kwargs)). Since the former is more > common than the latter, the current choice is optimal.
Wrappers that adapt or add some arguments (think partial()) aren't all that uncommon, even when speed is not irrelevant. But I agree that actual keyword arguments should rarely be involved in those calls. Typically, it's calls with 1 to ~3 positional arguments that occur in performance critical situations. Often just one, rarely more, and zero arguments is a fast case anyway. Keyword arguments will always suffer some kind of penalty compared to positional arguments, regardless of how they are implemented (at runtime). But they can easily be avoided in many cases, and anyone designing a performance relevant API that *requires* keyword arguments deserves to have their code forked away from them. :) The current keyword calling conventions seem fine with me and I do not see a reason why we should invest discussion time and distributed brain capacity into "improving" them. Stefan PS: Passing keyword arguments through wrappers unchanged might be a case to consider in the future, but the calling PEPs don't seem the right place to discuss those, as it's not just a call issue but also a compiler issue. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
