[Python-Dev] Switch statement (original) (raw)

Guido van Rossum guido at python.org
Fri Jun 23 21:05:42 CEST 2006

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 = ...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: = static ...do? In a function namespace, do we calculate expression, assign it to the 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 each pass through during runtime, making it effectively equivalent to: = I hope it's the latter (assign it to the local from a const table at the point of the ' = 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/)

More information about the Python-Dev mailing list