On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
