Phillip J. Eby wrote:
> At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>> [Phillip Eby]
>>> I would like to be able to use switches on types, enumerations, and the
>> like.
>>
>> Be careful about wanting everything and getting nothing.
>> My proposal is the simplest thing that gets the job done for key use cases
>> found
>> in real code.
>
> It's ignoring at least symbolic constants and types -- which are certainly
> "key use cases found in real code".
Raymond's idea is a step on the road, not necessarily the endpoint. It's
cleverness lies in the fact that it removes the dependency between getting a
switch statement that will help with the standard library's current use cases
and getting static expressions.
Being able to build a dispatch table as "hashable object -> case name" instead
of having to build it as "hashable object -> callable object" is a significant
improvement over the status quo, even if it doesn't solve everything. It
doesn't get rid of the need for the separate dispatch table, but it does
eliminate the need to turn everything into a separate, and it also allows the
cases to modify the function's local namespace.
Note that, *if* static expressions or an equivalent are added later, there is
nothing preventing them being integrated (implicitly or otherwise) into
Raymond's simplified switch statement.
The simplified proposal breaks the current discussion into two separately
PEP-able concepts:
a. add a literals-only switch statement for fast local dispatch (PEP 275)
b. add the ability to designate code for once-only evaluation
Removing the limitations on the initial version of the switch statement would
then be one of the motivating use cases for the second PEP (which would be a
new PEP to thrash out whether such evaluation should be at first execution
time so it works everywhere, or at function definition time, so it only works
at all in functions and behaves very surprisingly if inside a loop or
conditional statement).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
