Re: [Python-ideas] Idea: Lazy ... statement
On Mon, Oct 13, 2008 at 4:12 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
from foo.thing lazily import Thing from foo.stuff lazily import Stuff
Since this can be (awkwardly) done now, I don't think the problem is big enough for another keyword. On the other hand, a "lazy" keyword that worked in other contexts might have some merit. That would solve at least one major objection to setdefault-style functions. def setdefault(self, k, lazy d=None): ... or even lazy def yikes(msg): """Something went very wrong; report for debugging""" import logging ...logging config setup... ... Note that I'm not yet ready to volunteer on fleshing out the details, let alone how to implement it efficiently. (Would it require the moral equivalent of quasiquoting?) -jJ
On Tue, Oct 14, 2008 at 4:39 PM, Mathias Panzenböck <grosser.meister.morti@gmx.net> wrote:
That would solve at least one major objection to setdefault-style functions.
def setdefault(self, k, lazy d=None): ...
I don't understand what this lazy keyword should do?
"Hey, this next thing that you were about to execute? Don't do it yet." Part of the problem with setdefault is that calculating the default can be expensive. profile.setdefault(user, askuser()) This should get the user's stored profile; if there is no stored setting, it should ask the user and save the result for future reference. Unfortunately, askuser() gets evaluated before setdefault is called, so the user is *always* asked, "just in case". profile.setdefault(user, lazy askuser()) would say not to bother the user *unless* the default were actually needed. (Just as the lazy import wouldn't bother setting up the other module unless/until it were actually needed.) lazyness can seem pretty important in some programming styles, but ... those styles don't seem to be such a good fit for python anyhow. Whether there are enough use cases in typical python ... I'm not sure. (But I'm pretty sure that import alone doesn't make it.) -jJ
The title of this thread is lazy... statement but it seems to me that expressions are the natural unit. If I want to do lazy evaluation today, I would use something like f(a, b, lambda: g(a,b)) where of course the g(a,b) is only evaluated when f wants to evaluate it. Of course f is responsible for explicitly evaluating that lambda. I think a lambda-like syntax like this: f(a, b, lazy: g(a,b)) would be easy to understand. Note that this puts the responsibility on the caller's side to say that the expression is lazy. That is, we don't do def f(a, b, lazy: d): or lazy: def(a, b, d): although this is allowed: def f(a, b, d=lazy: g()) There are several reasons I put the responsibility on the caller's side: (1) The caller is in the best position to know if evaluating a lazy expression is expensive enough that it's worth making lazy, and if making an expression lazy changes the order of evaluation in a bad way. (2) When we see a function call, we don't know for sure which function will be called so we'd have to compile both the inline and the lazy evaluation for each parameter. I'm not sure what this makes for the import case. --- Bruce
On Wed, Oct 15, 2008 at 5:25 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Jim Jewett wrote:
Part of the problem with setdefault is that calculating the default can be expensive.
There's already a superior replacement for setdefault, i.e. use a defaultdict.
Only if the default can be calculated by the dict itself. If some information from the calling site is needed, there still isn't a good answer. That is a rare case, but does overlap with the cases where calculation actually is expensive. -jJ
Jim Jewett wrote:
Since this can be (awkwardly) done now, I don't think the problem is big enough for another keyword.
Yes, it can be done, but not without confounding static analysis tools. That's the reason I'm suggesting a dedicated syntax. An alternative would be to establish a convention for expressing it that static tools could recognize, although it's hard to think of something that wouldn't look ugly.
I'm calling hypergeneralization on these -- they would be doing very different things from what I'm suggesting. -- Greg
On Tue, Oct 14, 2008 at 4:39 PM, Mathias Panzenböck <grosser.meister.morti@gmx.net> wrote:
That would solve at least one major objection to setdefault-style functions.
def setdefault(self, k, lazy d=None): ...
I don't understand what this lazy keyword should do?
"Hey, this next thing that you were about to execute? Don't do it yet." Part of the problem with setdefault is that calculating the default can be expensive. profile.setdefault(user, askuser()) This should get the user's stored profile; if there is no stored setting, it should ask the user and save the result for future reference. Unfortunately, askuser() gets evaluated before setdefault is called, so the user is *always* asked, "just in case". profile.setdefault(user, lazy askuser()) would say not to bother the user *unless* the default were actually needed. (Just as the lazy import wouldn't bother setting up the other module unless/until it were actually needed.) lazyness can seem pretty important in some programming styles, but ... those styles don't seem to be such a good fit for python anyhow. Whether there are enough use cases in typical python ... I'm not sure. (But I'm pretty sure that import alone doesn't make it.) -jJ
The title of this thread is lazy... statement but it seems to me that expressions are the natural unit. If I want to do lazy evaluation today, I would use something like f(a, b, lambda: g(a,b)) where of course the g(a,b) is only evaluated when f wants to evaluate it. Of course f is responsible for explicitly evaluating that lambda. I think a lambda-like syntax like this: f(a, b, lazy: g(a,b)) would be easy to understand. Note that this puts the responsibility on the caller's side to say that the expression is lazy. That is, we don't do def f(a, b, lazy: d): or lazy: def(a, b, d): although this is allowed: def f(a, b, d=lazy: g()) There are several reasons I put the responsibility on the caller's side: (1) The caller is in the best position to know if evaluating a lazy expression is expensive enough that it's worth making lazy, and if making an expression lazy changes the order of evaluation in a bad way. (2) When we see a function call, we don't know for sure which function will be called so we'd have to compile both the inline and the lazy evaluation for each parameter. I'm not sure what this makes for the import case. --- Bruce
On Wed, Oct 15, 2008 at 5:25 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Jim Jewett wrote:
Part of the problem with setdefault is that calculating the default can be expensive.
There's already a superior replacement for setdefault, i.e. use a defaultdict.
Only if the default can be calculated by the dict itself. If some information from the calling site is needed, there still isn't a good answer. That is a rare case, but does overlap with the cases where calculation actually is expensive. -jJ
Jim Jewett wrote:
Since this can be (awkwardly) done now, I don't think the problem is big enough for another keyword.
Yes, it can be done, but not without confounding static analysis tools. That's the reason I'm suggesting a dedicated syntax. An alternative would be to establish a convention for expressing it that static tools could recognize, although it's hard to think of something that wouldn't look ugly.
I'm calling hypergeneralization on these -- they would be doing very different things from what I'm suggesting. -- Greg
participants (4)
-
Bruce Leban -
Greg Ewing -
Jim Jewett -
Mathias Panzenböck