On Thu, May 14, 2009 at 3:20 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Thu, 14 May 2009 12:41:17 pm Bruce Leban wrote:<br>
<br>
> Explicit is better than implicit. There's a thunk getting created<br>
> here, right? Don't you want that to be obvious? I do.<br>
<br>
</div>No, I don't want it to be obvious. I don't care about thunks, I care<br>
that x gets bound at runtime. I don't care what the implementation is:<br>
whether it is a thunk, eval(), voodoo or something else, just so long<br>
as it works.<br>
<br>
As for your argument that it is better to be explicit, when you want to<br>
add two numbers and compare them with a third, do you write:<br>
<br>
(1 .__add__(1)).__eq__(2)<br>
<br>
instead of<br>
<br>
1+1 == 2? </blockquote><div><br>Absolutely not. This is a false analogy. The anology would be having an implicit multiplication operator and writing (a b c) instead of (a * b * c).<br> <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<snip> The syntax shouldn't depend on the<br>
implementation.<br>
<br>
lambda is already disliked by many people, including Guido. I don't<br>
think any suggestion that we make lambda more confusing by giving it<br>
two very different meanings ("create a thunk" inside function parameter<br>
lists, and "create a function" everywhere else) will be very popular on<br>
python-dev.<br>
<br>
</blockquote><div>I'm *not* suggesting a new meaning for lambda! This is the same meaning that it has right now. The new meaning is the decorator attached to the default assignment that says evaluate that lambda. <br>

</div><br></div>I'll use an @dynamic decorator-like syntax to illustrate. These would be valid:<br><br>def foo(a, b = @dynamic lambda: []):<br>def foo(a, b = @dynamic lambda: list()):<br>
def foo(a, b = @dynamic list):<br>def foo(a, b = @dynamic random.random):<br><br>and this would not:<br><br>def foo(a, b = @dynamic [])<br>def foo(a, b = @dynamic 5)<br><br>because @dynamic says that the thing that follows is called to generate a dynamic default parameter value and you can't call [] or 5.<br>

<br>My point about creating a thunk is *not* an implementation detail. The point here is that if you use one of the forms above with a lambda, it's the lambda creating a thunk/closure/voodoo thing at this point in the program, *not* the @dynamic decorator. The scope of that lambda is exactly what it looks like it is with or without the @dynamic decorator. Likewise, in the random.random, example, it's the value of random.random at the time the function is defined, not some later value that might be assigned to that name.<br>

<br>If you use some other syntax that doesn't look like a lambda, I have to learn the scoping rules for that syntax. I already know the rules for lambda.<br><br>--- Bruce<br>