On Sun, Oct 31, 2021 at 12:31 PM David Mertz, Ph.D. <david.me...@gmail.com> wrote: > > On Sat, Oct 30, 2021, 6:29 PM Chris Angelico <ros...@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 problem here is that you're creating an object that can be evaluated in someone else's scope. I'm not creating that. I'm creating something that gets evaluated in its own scope - the function currently being defined. If you want to create a "deferred" type, go ahead, but it won't conflict with this. There wouldn't be much to gain by restricting it to function arguments. Go ahead and write up a competing proposal - it's much more general than this. > The similarity to decorators feels wrong, even though I think it's probably > not ambiguous syntactically. > The way you've written it, it's bound to an assignment, which seems very odd. Are you creating an arbitrary object which can be evaluated in some other context? Wouldn't that be some sort of constructor call? > 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. > A trivial use? But a very common one. The more general case would be of value, but would also be much more cognitive burden. But feel free to write something up and see how that goes. Maybe it will make a competing proposal to PEP 671; or maybe it'll end up being completely independent. ChrisA _______________________________________________ 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/6C667Y4SAAXINH2HGQZY42ISWKIUAZVN/ Code of Conduct: http://python.org/psf/codeofconduct/
