On Thu, Dec 9, 2021 at 2:22 PM Brendan Barnwell <brenb...@brenbarn.net> wrote:
> Your example there is very simple. But for me a lot of it comes down
> to this:
>
> def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)):
>
> The PEP envisions a world in which you can have a list of arguments
> like that, alternating back and forth between early and late binding,
> and they can refer to each other in arbitrary ways, and the semantics
> will differ from one argument to another (in that, e.g., for c the
> arguments a and b will be evaluated in the enclosing scope, whereas for
> d they are evaluated in the function scope). And yet none of the
> late-bound defaults will exist as objects or be accessible or creatable
> in any way apart from in function signatures, so all of this complexity,
> insofar as it exists, is necessarily going to be crammed entirely into
> function signatures, and also provide no benefit anywhere else.
As with every other complex construction, it can be misused. It's
certainly possible to use a list comprehension to replace any sort of
loop, no matter what the purpose; but for the most part, people don't
do that.
It is the simplest cases which are the most useful, and also the least
likely to cause confusion.
Remember, though: The comparison should be to a function that looks like this:
def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
if b is _SENTINEL1: b = {}
if c is _SENTINEL2: c = some_function(a, b)
if d is _SENTINEL3: d = other_function(a, b, c)
If you find the long-hand form more readable, use the long-hand form!
It's not going away. But the introspectability is no better or worse
for these two. The late-bound defaults "{}", "some_function(a, b)",
and "other_function(a, b, c)" do not exist as objects here. Using PEP
671's syntax, they would at least exist as string constants, allowing
you to visually see what would happen (and, for instance, see that in
help() and inspect.signature).
And of course, there will be cases where you mix and match:
def f(a=[], b=>{}, c=_SENTINEL, d=_SENTINEL): ...
Which is also perfectly acceptable. Sentinels don't have to be
abolished from the language.
Is there benefit in replacing just one simple case with something that
would be more readable, more program-comprehensible, etc, etc, even if
the others stay as they are?
ChrisA
_______________________________________________
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/FSCTZGYALZPLELM2DGKPUJ4GPAQBV73A/
Code of Conduct: http://python.org/psf/codeofconduct/
