[Python-Dev] once [was: Simple Switch statementZ]

[Guido van Rossum]

On 6/28/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 6/28/06, Guido van Rossum <guido at python.org> wrote:
> > On 6/28/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> It basically requires a reserved word.
>
>     def f(a, b="key",  __func__.extra=i):
>         if __func__.extra < 43: ...
>
> > And anyway this would be way too complex for the little
> > lambda I was using as an example.
>
>     def index_functions(n):
>         return [(lambda __func__.i=i: i) for i in range(n)]

I told you it was ugly. :-)

> > I'm not sure what you mean by "load time".
>
> The first time a module is imported.  When running from a .py file,
> this is the same as compile time.
>
> I didn't say compile-time because I don't want it frozen permanently
> for the entire installation when the .pyc file is first written.

So it won't have access to imported modules, contradicting your
earlier statement " which might well involve names imported from
another module".

> > > > A capture expression inside "if 0:" would still be
> > > > captured to simplify the semantics (unless the compiler can prove that
> > > > it has absolutely no side effects).
>
> > > Running code that was guarded by "if 0:" sounds like a really bad idea.
>
> > Assuming that the compiler will treat code guarded by "if 0:"
> > different from code guarded by "if x:" where you happen to know that x
> > is always false sounds like a really bad idea too.
>
> The indent rules mean it will never be reached, so it can't have side
> effects.  I expect that "if 0:  push_the_red_button" will not risk
> pushing the red button.
>
> Freezing a once-variable at funcdef time means that I have to look
> inside the indent after all.  "If 0:" is just an especially bad
> special case.

So we have what seems to be an impasse. Some people would really like
once-expressions to be captured at def-time rather than at the first
execution per def; this is the only way to use it so solve the "outer
loop variable reference" problem. Others would really hate it if a
once could be hidden in unreachable code but still execute, possibly
with a side effect.

I'm not sure that the possibility of writing obfuscated code should
kill a useful feature. What do others think? It's basically impossible
to prevent obfuscated code and we've had this argument before:
preventing bad code is not the goal of the language; encouraging good
code is.

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