On 16 Jun 2006, at 00:49, Phillip J. Eby wrote:
At 11:45 PM 6/15/2006 +0100, Nicko van Someren wrote:
On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
... The lack of a switch statement doesn't really bother me personally, since I tend to just write my state machine type code so that it works off a dictionary that I define elsewhere,
Not trying to push more LISP into python or anything, but of course we could converge your method and the switch statement elegantly if only we could put whole suites into lamdbas rather than just single expressions :-)
As has already been pointed out, this
1) adds function call overhead, 2) doesn't allow changes to variables in the containing function, and 3) even if we had a rebinding operator for free variables, we would have the overhead of creating closures.
Noted. I find (2) the most compelling issue. I was merely suggesting a succinct way to express the model that Nick Cohglan was espousing.
The lambda syntax does nothing to fix any of these problems, and you can already use a mapping of closures if you are so inclined. However, you'll probably find that the cost of creating the dictionary of closures exceeds the cost of a naive sequential search using if/elif.
The smiley was supposed to indicate that this was not an entirely serious suggestion; my apologies if the signal was lost in transmission. In the equivalent if/elif to a switch you're only comparing a single value against a set of pre-computed values, and expecting to only do half the tests, so it's almost certainly going to be quicker than sorting out the whole set of closures. I do however have a bug-bear about lambdas being restricted to single expressions, but maybe that's just me. Nicko