On Thu, Dec 9, 2021 at 2:22 PM Brendan Barnwell <brenbarn@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