Chris Angelico writes: > So [a "deferred object" is] a lambda function that gets called the > moment you touch it in any way.
I'll take that as a question, though you present it like a fact. It's a code object plus "other stuff" that gets called automatically when dereferencing a name in most contexts (like a descriptor but works with "plain" identifiers rather than attribute names). Other cases I'm not sure about, and I don't know whether they can be resolved in a way *generally* useful enough to make them worth adding. For example, let a and b[0] both refer to a "deferred object". 1. The statement x = a will evaluate the contained expression. 2. I don't know when x = b[0] will evaluate the contained expression. 3. I don't know when f(a) will evaluate the contained expression. 4. There will be APIs such as "isdeferred(x)" and "unevalled x" that do not evaluate the contained expression. I think my answers are "2. before binding x" and "3. as in PEP 671", but I'm somewhat unsure of both, since I don't know David's and Eric's use cases. (FWIW, the alternatives I had in mind were "2. when x is dereferenced" and "3. when a is dereferenced in the body of f". There may be others.) The "other stuff" mentioned above similarly depends on use cases that I don't know. I suspect that "use cases I don't know" are characteristic of everyone's reluctance to do a "generic deferred evaluation" PEP. I get the feeling there are a number of them. > > > (Another theoretical difference is that a deferred expression is > > > parsed in the context of its *usage* rather than its *definition*, but > > > that would break all manner of things in Python and is quite > > > impractical.) > > > > I'm a little confused by "theoretical" and "parsed". > > What I mean is that I don't know whether you intend it one way or the > other, so I don't know whether it's an actual difference in your > proposal, or something that could in theory be. Do you not realize that "you" is plural, and "proposal" is not unique at this point? In particular, I was asking about you channelling Eric. I was not making any statement about my own proposal (which is starting to gel but until a day or so ago was 100% nonexistent), or Eric's for that matter. I still don't understand why time of parsing matters. Do you mean time of compilation? > If name lookups in these temporary expressions have to refer to > names in the target function, not in their current context, it > causes all kinds of problems. That's what Ruby blocks do, and Rubyists love them. They certainly don't think blocks have huge problems. Alternatively, it would certainly be possible to do as Common Lisp does, and provide for optional closure over creation-time arguments as well as access to namespaces active at evaluation time via explicit APIs. Sure, all this would be complex, and maybe "too complicated to be a good idea". On the other hand, there may be other use cases that can take advantage of evaluation of a simple reference to z after z = defer foo(*args) besides the case of late binding of function arguments. If those use cases are sufficiently compatible and compelling, it may be possible to define the implicit APIs and add explicit APIs as needed in the future. > Is that your intention? Otherwise, what is x there? I don't understand why you are pushing so hard for these details, when I doubt any of the advocates of a more general deferred evaluation facility have communicated with each other yet, and the details probably vary substantially. And even David has acknowledged that he doesn't have a worked-out proposal at the moment, only a wisp of a threat to write one. It's reasonable to say, as you have, "my proposal is the only one on the table." That's true (and acknowledged by all who prefer to wait for a generic deferred evaluation proposal), but existence of a proposal is a necessary condition for adoption, not sufficient. If nonexistence of a competing proposal is not the point you're trying to make, I'm not sure what you're after in this subthread. Please don't waste your time answering any implicit questions in this post. If you find them interesting, go right ahead, but I'm not asking for answers from you, I'm trying to provide answers to your questions as I understand them. (David, Eric, and any lurkers may have different answers, though!) Regards, Steve _______________________________________________ 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/TQVLHXENCFAMQCCBLC2KIUFUPU5PMEGU/ Code of Conduct: http://python.org/psf/codeofconduct/