
On 10/30/2021 10:08 PM, Christopher Barker wrote:
I'm a bit confused as to why folks are making pronouncements about their support for this PEP before it's even finished, but, oh well. I think it's safe to say people are opposed to the PEP as it current stands, not in it's final, as yet unseen, shape. But I'm willing to use other words that "I'm -1 on PEP 671". You can read my opposition as "as it currently stands, I'm -1 on PEP 671". As for what seems like one major issue:
Yes, this is a kind of "deferred" evaluation, but it is not a general purpose one, and that, I think, is the strength of the proposal, it's small and specific, and, most importantly, the scope in which the expression will be evaluated is clear and simple.
And to me and others, what you see as a strength, and seem opposed to changing, we see as a fatal flaw. What if the walrus operator could only be used in "for" loops? What if f-strings were only available in function parameters? What if decorators could only be used on free-standing functions, but not on object methods? In all of these cases, what could be a general-purpose tool would have been restricted to one specific context. That would make the language more confusing to learn. I feel you're proposing the same sort of thing with late-bound function argument defaults. And I think it's a mistake. If these features had been added in their limited form above, would it be possible to extend them in the future? As they were ultimately implemented, yes, of course. But it's entirely possible that if we were proposing the limited version above we could make a design decision that would prevent them from being more widely used in the future. The most obvious being the syntax used to specify them, but I think that's not the only consideration.
In contrast, a general deferred object would, to me, be really confusing about what scope it would get evaluated in -- I can't even imagine how I would do that -- how the heck am I supposed to know what names will be available in some function scope I pass this thing into??? Also, this would only allow a single expression, not an arbitrary amount of code -- if we're going to have some sort of "deferred object" -- folks will very soon want more than that, and want full deferred function evaluation. So that really is a whole other kettle of fish, and should be considered entirely separately.
And again, this is where we disagree. I think it should be considered in the full context of places it might be useful. I (and I think others) are concerned that we'd be painting ourselves into a corner with this proposal. For example, if the delayed evaluation were available as text via inspect.Signature, we'd be stuck with supporting that forever, even if we later added delayed evaluation objects to the language. I also have other problems with the PEP, not specifically about restricting the scope of where deferred evaluations are allowed. Most importantly, that it doesn't add enough expressiveness to the language to justify its existence as a new feature that everyone would have to learn. But also things such as: Where do exceptions get caught and handled (only by the caller)? How would you pass in "just use the default" from a wrapper function? And others, but even if they were all addressed except for the restricted nature of the feature, I'd still be -1 on the PEP. Eric