On Fri, 17 Feb 2017 at 23:14 Joshua Morton <joshua.morto...@gmail.com> wrote:
> @ Ed > > Its my understanding that d[k] is always d[k], even if d or k or both are > delayed. On the other hand, `delayed d[k]` would not be, but you would need > to explicitly state that. I think its worth expanding on the example Joseph > made. > > I think it makes sense to consider this proposal to be `x = delayed > <EXPR>` is essentially equivalent to `x = lambda: <EXPR>`, except that > there will be no need to explicitly call `x()` to get the delayed value, > instead it will be evaluated the first time its needed, transparently. > This, for the moment, assumes that this doesn't cause enormous interpreter > issues, but I don't think it will. That is, there is no "delayed" object > that is created and called, and so as a user you really won't care if an > object is "delayed" or not, you'll just use it and it will be there. > > Do you understand this proposal differently? > > --Josh > Chris mentioned something about it being difficult to decide what evaluates a delayed thing, and what maintains it. This tangent started with my suggesting that operators should maintain delayed-ness iff all their operands are delayed, with ., [] and () as exceptions. That is, I'm suggesting that d[k] always evaluate d and k, but a + b might defer evaluation if a and b are both delayed already. Roughly, I guess my rationale is something like "let operators combine multiple delayed-objects into one, unless that would break things"—and at least by convention, operators that aren't ., [] or () don't have behaviour that would be broken. Ed
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
