items.sort(key=compute_sort_value) where:
Now, the body of compute_sort_value appears exactly where it is executed: within the call to items.sort().
No it doesn't. The function definition appears outside the call to sort(). For the function definition to appear inside the call to sort, you'd need to write something like
Yes, it does appear within the call. The call is more than just the parameters in parentheses. It begins with "items.sort" and ends (in this case) with then end of the "where" clause
items.sort(key=lambda item: value)
The idea behind "where" clauses is not to replace lambdas. In fact, they are useful together: items.sort(key=mysort) where: mysort = sort_key_function_factory( with, many, arguments) which to many is preferable over: items.sort(key=lambda item:sort_key_function_factory(with, many, arguments)) Even though you can split it: items.sort(key=lambda item: sort_key_function_factory(with, many, arguments) )
In this case, the lambda only occurs inside the call to sort() -- it's inaccessible to anything else (excluding trickery inside of sort() itself). By comparison, the compute_sort_value() function exists inside the where-block, and therefore is accessible to everything else inside that block:
items.sort(key=compute_sort_value) where: def compute_sort_value(item): return value print compute_sort_value('testing testing 1 2 3')
That would be useful for debugging. Really though, the whole thing comes down to a matter of taste and visual presentation. Some will find "where" completely intuitive and a natural way to work. Others will loathe it (though as has been pointed out, it really makes using Haskell functions easier to write and to read.) On the whole though, it's a +1 for me