On Sun, 31 Oct 2021 at 12:45, Eric V. Smith <e...@trueblade.com> wrote: > > 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".
Same for me. > > 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. I agree with Eric. I can see the value in a small and specific proposal, if there's a small and specific issue involved. But as the discussions have progressed, it seems to me that the small and specific issue that we *thought* was involved, has wider and more general implications: 1. There's a broader question of being able to tell if an argument was left unspecified in the call. Defaulting to None, and using a sentinel value, both try to address this in specific limited ways. PEP 671 is addressing the same issue, but from a different angle, because the code to supply the late bound default has to say, in effect, "if this argument wasn't supplied, evaluate the late-bound expression and use that as a default". That suggests to me that a better mechanism than "use (*args, **kwargs) and check if the argument was supplied" would be generally useful, and PEP 671 might just be another workaround that could be better fixed by addressing that need directly. 2. The question of when the late-bound default gets evaluated, and in what context, leads straight into the deferred expression debate that's been ongoing for years, in many different contexts. Maybe PEP 671 is just another example of something that wouldn't be an issue if we had deferred expressions. Sure, "now is better than never" might apply here - endlessly sticking with the status quo because we can't work out the details of the grand solution to everything is a classic "perfect is the enemy of the good" situation. But equally, maybe what we have already is *good enough*, and there's no real rush to solve just this one piece of the puzzle. It's tempting to solve the bit that we can see clearly right now, but that shouldn't blind us to the possibility of a more flexible solution that addresses the issue as part of a more general problem. > > 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. This is for me the main issue where I think "constraining the design of the broader feature later" really hurts. There's absolutely no doubt in my mind that *if* we already had deferred expressions, then we'd expose late-bound defaults as delayed expressions in the function's signature. If we implement them as strings just because we don't yet have delayed expressions, then when we do look at designing delayed expressions, we're stuck with the backward compatibility problem of how we fit them into function signatures without breaking all the code that's been written to expect a string. Yes, that's all 15 obscure utilities with a total user base of about 5 people ;-), I completely accept that this is a very niche issue - but backward compatibility often ends up concerned with such details, and they can be the hardest ones to fix. > 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. These all seem like reasonable questions to me, and it feels to me that they are the sort of thing that is getting sidelined by the big deferred expression debate. Even if that debate ends up with a resolution, these questions will remain - and I can easily imagine everyone being so burned out at that point that we end up with sub-optimal, or even broken, answers to those questions, or possibly they just get completely forgotten about. Anyway, this discussion will no doubt take its course whatever I say. And once we have a final PEP, we can raise these issues again if they haven't been addressed. But until a new version of the PEP is released that addresses the points made so far, I don't think I have anything else to add, and the mountain of email is getting so big that I'm not even trying to follow the details of the arguments any more. So I'll wait and see where this ends up before commenting any more. Paul _______________________________________________ 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/R4AM4YRHAZ5TZBC72LFX65KX4KI4R2UO/ Code of Conduct: http://python.org/psf/codeofconduct/
