[Python-Dev] Switch statement

[Josiah Carlson]

"Guido van Rossum" <guido at python.org> wrote:
> On 6/23/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > "Guido van Rossum" <guido at python.org> wrote:
> > > Independent from this, I wonder if we also need static names of the form
> > >
> > >   static <name> = <expression>
> > >
> > > which would be similar to
> > >
> > >   <name> = static (<expression>)
> > >
> > > but also prevents <name> from being assigned to elsewhere in the same scope.
> >
> > * I don't particularly care for the literal syntax of static.
> 
> What do you mean by "literal syntax of static"? Do you mean 'static'
> <atom> or 'static'  <name> '=' <expression>? Or something else?

The existance of the static keyword and its use in general.

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.

I believe that static is generally fine for the...
    static <expression>
... case, whether it is prefixed with a '<name> =', or some other
operation on the value.

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.  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?  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).


> > For general variables, like say; math.pi, re.DOTALL, sys.maxint, len,
> > int, Exception, etc., many of them are merely references to their values,
> > that is, there are no value manipulations.  This case is quite
> > conveniently covered by Raymond's "Decorator for BindingConstants at
> > compile time", a sexy decorator available in the cookbook [1].  That
> > decorator can handle all of the non-modifying value assignments, and in
> > the case of Frederick's previously described:
> 
> But it is an absolutely yucky approach. It modifies byte code. That
> makes it break in future Python versions (Python's byte code is not
> standardized across versions), as well in Jython, IronPython, and
> sandboxed Python (which will make a come-back, see Brett's post).

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.

It seems that this particular operation can be cumbersome, is a
maintenance nightmare, and isn't applicable to non-CPython, so it
violates my reasons for 'shouldn't become syntax'.


If it makes others happy, static is fine with me.

 - Josiah