[Python-Dev] once [was: Simple Switch statementZ] (original) (raw)

Guido van Rossum guido at python.org
Wed Jun 28 19:33:19 CEST 2006

On 6/28/06, Jim Jewett <jimjjewett at gmail.com> wrote:

On 6/28/06, Guido van Rossum <guido at python.org> wrote:

> def indexfunctions(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/)

More information about the Python-Dev mailing list