[Python-Dev] once [was: Simple Switch statementZ]
jimjjewett at gmail.com
Wed Jun 28 20:38:04 CEST 2006
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.
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
More information about the Python-Dev