On Sat, Oct 30, 2021, 6:29 PM Chris Angelico <rosuav@gmail.com> wrote:
At first I thought it might be harmless, but nothing I really care about. After the discussion, I think the PEP would be actively harmful to future Python features.
It's nothing more than an implementation detail. If you want to suggest -
or better yet, write - an alternative implementation, I would welcome it. Can you explain how this is "actively harmful"?
Both the choice of syntax and the discussion of proposed implementation (both yours and Steven's) would make it more difficult later to advocate and implement a more general "deferred" mechanism in the future. If you were proposing the form that MAL and I proposed (and a few others basically agreed) of having a keyword like 'defer' that could, in concept, only be initially available in function signatures but later be extended to other contexts, I wouldn't see a harm. Maybe Steven's `@name=` could accommodate that too. I'm not sure what I think of a general statement like: @do_later = fun1(data) + fun2(data) I.e. we expect to evaluate the first class object `do_later` in some other context, but only if requested within a program branch where `data` is in scope. The similarity to decorators feels wrong, even though I think it's probably not ambiguous syntactically. In a sense, the implementation doesn't matter as much if the syntax is something that could be used more widely. Clearly, adding something to the dunders of a function object isn't a general mechanism, but if behavior was kept consistent, the underlying implementation could change in principle. Still, the check for a sentinel in the first few lines of a function body is easy and fairly obvious, as well as long-standing. New syntax for a trivial use is just clutter and cognitive burden for learners and users.