On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> I use dict base dispatching in a number of my programs and like it with
> the exception I need to first define all the code in functions (or use
> lambda) even if they are only one line. So it results in a three step
> process, define functions, define dict, and then call it. And I need
> to make sure all the function calls use the same calling signature. In
> some cases I'm passing variables that one function doesn't need because
> it is needed in one of the other cases.
>
> So modeling the switch after dictionary dispatching more directly where
> the switch is explicitly defined first and then used later might be good
> both because it offers reuse in the current scope and it can easily be
> used in code that currently uses dict style dispatching.
>
> switch name:
> 1:
> ...
> TWO:
> ...
> 'a', 'b', 'c':
> ...
> in range(5,10):
> ...
> else:
> ...
>
> for choice in data:
> do choice in name: # best calling form I can think of.
It looks like your proposal is to change switch into a command that
defines a function of one parameter. Instead of the "do <expression>
in <switch>" call you could just call the switch -- no new syntax
needed. Your example above would be
for choice in data:
name(choice) # 'name' is the switch's name
However, early on in the switch discussion it was agreed that switch,
like if/elif, should not create a new scope; it should just be a
control flow statement sharing the surrounding scope. The switch as
function definition would require the use of globals.
Also, it would make sense if a switch could be a method instead of a function.
I realize that by proposing a new invocation syntax (do ... in ...)
you might have intended some other kind of interaction between the
switch and the surrounding scope. but exactly what you're proposing
isn't very clear from your examples, since you don't have any example
code in the case suites, just "...".
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
