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

[Jim Jewett]

On 6/28/06, Guido van Rossum <guido at python.org> wrote:
> On 6/28/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 6/28/06, Guido van Rossum <guido at python.org> wrote:

> > >   def index_functions(n):
> > >     return [(lambda i=i: i) for i in range(n)]

> > > which works but has the disadvantage of returning a list of functions
> > > of 0 or 1 argument

> > Another alternative might be letting functions get at themselves,
> > rather than just their names.  (Methods can save attributes on self,
> > but functions are out of luck if someone else reused their name.)

> This has been proposed before. Because (as you say) the function name
> is not generally safe to use, there's no good API; all proposals I've
> seen are ugly.

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)]

> > > Capture expressions outside functions would be illegal or
> > > limited to compile-time constant expressions (unless someone has a
> > > better idea).

> > At a minimum, it should be able to capture the expression's current
> > value at load-time, which might well involve names imported from
> > another module.

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

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

-jJ