[Python-3000] Switch and static, redux

[Guido van Rossum]

I'm sitting here at EuroPython listening to a speaker who has analyzed
interaction patterns on python-dev. (She represents me as a red dot
and Raymond H as a yellow star in a diagram. I'm trying not to read
too much into that. :-)

One of her comments struck home: the open source development process,
which is often represented as exclusively taking place on line, is
actually augmented in a significant way by direct physical interaction
between developers at events like EuroPython (and PyCon, sprints
etc.).

A good example is the discussion I had over breakfast with Marc-Andre
and Samuele today. We rehashed switch and static/once, and I believe
the discussion has influenced my position a bit. Short version: I want
to press on with switch option 3 (def-time freezing), and I'm more
than ever skeptical about static or once.

(Incidentally, the semantics for this that most people like best,
including myself, are "captured each time 'def' is executed, which
makes 'once' a rather misleading name, I have to agree with Samuele.
So, for lack of a better word, I'll call it static for now, realizing
that that also isn't such a great name given its meaning in C and
Java.)

When I wrote PEP 3103 I ended with a conclusion that requested more
work on static/once ("precomputed values"). Talking about that this
morning, we noted that there were really two different uses of
'static' in the discussion. Both are intended to replace the use of
parameters with default values: one is the speed-up of a built-in or
other constant reference in a short method, while the other is the
capture of the current value of a variable in an outer scope
(typically a loop variable) when defining an inner function. These
cases are very different -- the optimization is just that, while the
variable capture is essential for the meaning of the inner function
(see another recent thread).

Samuele has been working for a long time on compiler tricks that will
do the optimization without hints from the user, and I think we can
change the rules of the language slightly to support this better
(these ideas aren't new). Import * is a bit of a snag but I think we
can find a way to make it work.

So the only remaining real use case for static is capturing the value
of an outer variable. But for this purpose, static expressions are
arguably just as clumsy if not more than the default-parameter trick
we currently use, especially if the captured value is used more than
once in the inner function; we'd have to write 'static x' each time,
or we have to write something like "x = static x" (if that's even
legal -- it might have to be "x_ = static x" if we disallow static
expressions referencing variables that are shadowed by locals).

None of this makes static very attractive compared to the
default-parameter trick. On the other hand, we (those present at the
breakfast table) all agreed that the switch statement can stand on its
own and does not need static to make it useful. Rather, freezing the
cases at def time, while different from anything Python does today,
produces no surprises when used idiomatically; and when used
non-idiomatically, the rule is simple enough to be able to predict
exactly what will happen, no matter how obfuscated the code.

So, my proposal is to give up on static, accept PEP 3103 with the
following options:
  - Syntax alternative 2+B (unindented cases, 'case in ...' for multiple cases).
  - Semantics option 3 (def-time freezing)

Do we need any more discussion about the PEP before I pronounce? (I'm
not super confident about the syntax alternatives yet.)

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