Guido van Rossum wrote:
> That sounds like a good solution all around. I hope that others can
> also find themselves in this.
>
> (1) An expression of the form 'static' <atom> has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluated every time.
> [Alternative 1: this is an error] [Alternative 2: it is evaluated
> before the module is entered; this would imply it can not involve any
> imported names but it can involve builtins] [Alternative 3:
> precomputed the first time the switch is entered]
+0.5 on this (still looking for some obvious drawback).
as for static in non-local scopes, an error feels more pythonic, but
that would complicate things if you want to move code from a local to a
global context (but how often do you do that ?). alternative 2 and 3
feels "too magic", again.
> (2) All case expressions in a switch have an implied 'static'.
I'm still -0 on implied static. and only +0 on switch/case, in general.
but it's growing on me.
(now, if you're written "implied 'break'", I'm all for it)
> (3) A switch is implemented using a dict which is precomputed at the
> same time its static expressions are precomputed. The switch
> expression must be hashable. Overlap between different cases will
> raise an exception at precomputation time.
+0 on switch/case, but -0.5 on a "in terms of implementation" rather
than "in terms of existing language constructs" approach.
as I mentioned before, I'd prefer if the switch/case/case-in/else was
defined in terms of a corresponding if/elif/else construct (but where
the controlling expression is only evaluated once).
after all, Python's a dynamic language, and I'm not convinced that I
would never want to use dynamically evaluated case values. just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR is a temporary variable, and case and case-in clauses can be
freely mixed, and leave the rest to the code generator. (we could even
allow "switch EXPR [as VAR]" to match a certain other sugar construct).
I'm also a K&R guy, so switch/case/case-in/else should all have the same
indent. anything else is just sloppy design.
> 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.
-0 from here; I don't see an obvious need for static names, but it may
grow on me.
> Also, I haven't heard a lot of thumbs up or down on the idea of using
>
> case X:
>
> to indicate a single value and
>
> case in S:
>
> to indicate a sequence of values.
+1 from here. it's obvious, useful, and therefore perfectly pythonic.
</F>