[Python-Dev] Switch statement

[Guido van Rossum]

On 6/23/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> You later stated that decorators were the wrong way of handling it. I
> believe that the...
>     static <name> = <expression>
> ...would require too many changes to what some regular python users have
> come to expect from at least module namespaces.  I have nothing
> constructive to say about the function local case.

It looks like "static NAME = EXPR" is still pretty controversial.
"NAME = static EXPR" seems to be getting universal +1s OTOH.

> Allowing things like 'value < static (math.pi / 2)' brings up the
> question of where the calculated value of (math.pi / 2) will be stored.
> Presumably it would be stored in a function or module const table, and
> that is fine.

A new category of data stored on the function object, computed at
function def time. It would be an array and there would be a new
opcode to load values in this array in O(1) time.

> But what does the operation:
>     <name> = static <expression>
> ...do?  In a function namespace, do we calculate expression, assign it
> to the <name> local on function definition and call it good?

That would be impossible; the local namespace doesn't exist when the
function object is created (except for the cells used to reference
variables in outer function scopes).

> Or do we
> load the stored evaluated <expression> each pass through during runtime,
> making it effectively equivalent to:
>     <name> = <literal>
> I hope it's the latter (assign it to the local from a const table at the
> point of the '<name> = static ...' line).

Yes, the latter  should be good enough.

[On Raymond's optimizing decorator]
> You make a good point.  It really is only usable in particular CPython
> versions at any one time, though I am generally of a different opinion:
> if for some desired operation X you can get identical functionality
> and/or speed improvements during runtime without additional syntax, and
> it is easy to use, then there is no reason to change syntax.

There problem with hacks like that decorator is that if it misbehaves
(e.g. you have a global that sometimes is reassigned) you end up
debugging really hairy code. The semantics aren't 100% clear.

I'm all for telling people "you can do that yourself" or even "here is
a standard library module that solves your problem". But the solution
needs to satisfy a certain cleanliness standard.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)