Rob Cliffe via Python-ideas writes: > Nobody has attempted (or at least completed) a PEP, never mind an > implementation, of a "generalized deferred object/type", in the last N > years or decades.
Haskell anything. Ruby blocks. Closer to home, properties and closures. So I don't think the object part is that hard, it's the syntax and semantics that's devilish. The evaluation syntax doesn't seem hard: you just reference the identifier the object is bound to. The creation syntax, though, probably needs to be concise, maybe even familiar, as Chris's proposal is. For the semantics, just in the case of defining an alternative to PEP 671, consider: if you just stuff a generalized deferred expression object into a formal argument's default, you still have to solve the problems that Chris's proposal does: where do you get the appropriate namespace to extract variable values from? and when do you do it? I do admire the elegance of Chris's solution to those questions, but if I were to fit a generalized deferred into that role, I might not adopt the "evaluate deferreds just before entering the function body proper" strategy. And then there's the question of whether referencing the deferred "collapses the waveform" into an object and binds it to the original identifier (as in Chris's proposal, but for more general contexts), or whether the deferred gets reevaluated each time in the current context (as Ruby blocks and Python properties usually do). 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/4H45HEKRIUVD52OYD3WNZXNSXWMQMXI2/ Code of Conduct: http://python.org/psf/codeofconduct/
