[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:
>
> >   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
>
> > I believe at least one poster has pointed out that 'once' (if defined
> > suitably) could be used as a better way to do this:
>
> Cleaner, yes.  But you would still have to remember the once, just as
> you have to remember the i=i, so I don't think it would actually save
> any confusion in practice.

Yes it would, to the reader; if you see a function with a default
argument now, you have to wonder if the default is there just to
capture a value.

> 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. And anyway this would be way too complex for the little
lambda I was using as an example.

> > Perhaps 'once' is too misleading a name, given the confusion you
> > alluded to earlier. Maybe we could use 'capture' instead? A capture
> > expression would be captured at every function definition time,
> > period.
>
> I think it would have the same problem; I would still want to read
> that as "The first time you run this, capture the result.", rather
> than "Capture the binding current at funcdef time, even though you're
> skipping all the other statements at this indent level."

"Capture" can have many meanings. Of course some people will still
misunderstand it. But it's more likely that they would look it up the
first time they saw it rather than assumign they knew what it meant.

> > 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". If you mean to do this
before the execution of the module body starts, then none of the
imported names are known (import is an executable statement, too).

> > 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. I'm happy to treat
elimination of "if 0:" blocks as optimizations. I'm not happy to state
into the language spec that the compiler should treat such code
differently. next, you're going to claim that a local variable only
assigned within such a block is not really a local (and references to
it outside the block should be treated as globals)...

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