Brendan Barnwell writes:
As I've said before, the problem is that the benefit of this feature is too small to justify this large change to the status quo.
I don't disagree with this (but the whole thing is a YAGNI fvo "you" = "me" so I'm uncomfortable agreeing as long "as x = x or default" keeps working ;-).
That is not even close to the situation envisioned in the proposal under discussion, because in the proposal this mysterious expression (the argument default), although not a first-class value, is going to be stored and used independently,
As far as I can see, this is exactly similar to the Lisp &aux, in the sense that there's no let form that a macro can grab in the body of the definition.[1] But the defaulted argument (see what I did there?) in both cases *is* a first-class value, stored in the usual place. In the case of Lisp &aux, as the current binding of the symbol on entry to the body of the defun, and in the case of Chris's proposal, as the current binding of the name on entry to the function body. It's always true in the case of Python that intropecting code is a fraught enterprise. Even in the case of def foo(x, y): return x + y foo(1, 1) it's not possible to introspect *how* foo produced "2" without messing with the byte code. I don't see this as very different: as has been pointed out several times, def bar(x = None): x = [] if x is None else x return x cannot be introspected without messing with the byte code, either. In both cases, the expression that produces the first-class object that x is bound to is explicit in the source code, just in different places, and invisible in the compiled code (unless you're willing to mess with the byte code, in which case you know where to find it after all). Footnotes: [1] True, said macro *can* see the &aux clause in the lambda form, reconstruct the let form, and do its evil work on the lambda, but such omniscience is possible because Lisp is the Language of the Gods, and rarely used by frail mortals.