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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
