On Wed, Jan 13, 2021 at 08:27:46PM +1100, Chris Angelico wrote:
> It's a lot faster for C-implemented functions to require positional
> parameters. A number of functions had help text that implied that they
> accepted keyword-or-positional args, but if you tried to call them
> with keyword args, they'd error out.
That's an unfortunate limitation of the docs, not a language feature.
One might even call it a documentation bug.
> And yes. PEP 457 and then PEP 570 introduced real positional-only
> arguments, and part of the debate surrounded the question "should we
> require that all C-implemented functions support keyword args?". Why
> have a performance hit on all C functions just for the sake of an
> arbitrary consistency? Instead, the language definition was changed to
> make this possible - and now we have, for instance, "len(obj, /)",
> which clearly does not accept len(obj="x"), but does accept len("x").
Sorry to be pedantic here... oh who am I fooling, I'm not sorry at all
*wink*
I think that if we are to be precise, and we should be, Python the
language has always supported positional-only arguments. What we lacked
was syntax for declaring named positional-only **parameters**.
There has always been at least two ways to implement positional-only
arguments:
- write your function in C;
- or use `*args` and process them yourself.
So that's not a new feature. The new feature gained in 3.8 was syntax to
define names for positional-only parameters in def statements.
This may not have been really obvious until after PEPs 457 and 570
because we were (and still are) fairly blasé about the difference
between arguments and parameters, and of calling things "positional"
regardless of whether they were actually positional-or-keyword or
positional-only.
In any case, this is very much a red herring. Function call syntax is
not an optimization, it is a syntactic feature of the language. The
ability to pass an argument by position, position-or-keyword, or keyword
is an element of language design. The choice of which ones to support
may be influenced by concerns about efficiency and speed, but that's as
far as it goes.
I think your earlier example of short-cutting equality tests with
identity tests is more relevant here.
[...]
> In theory, "x = (expr)" followed by "if x:" should perform the exact
> same checks as "if (expr):"; if it's okay to violate that principle
> for "if a and b:", then why not for "if a: pass"? Either way, the
> interpreter knows that any sane __bool__ function cannot affect the
> result.
Of course they can: the method can fail and raise an exception. That
could be due to a bug, or by design, as in numpy arrays and (soon)
NotImplemented.
Sane `__bool__` methods can have useful side-effects. More than once
I've debugged code by sticking some logging inside a method I knew would
be called, and that method could as easily be `__bool__` as any other.
--
Steve
_______________________________________________
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/RH2SYWCCCGZGDMPXWHJ5VMIKK3EQJIVZ/
Code of Conduct: http://python.org/psf/codeofconduct/
