[EMAIL PROTECTED] (Bengt Richter) writes: > Closure is the name for the whole thing, apparently, not just the > environment the procedure body needs, which was the aspect that I > (mis)attached the name to.
Which brings me to the point where I'd welcome more flexibility in writing to variables outside the local scope. This limitation most often kicks in in closed-over code in function objects, although it's a more general issue in Python's scoping. As we know, you can't write to variables that are both non-local and non-global (globals you can declare "global"). Now that effectively makes free variables read-only (although, the objects they point to can _still_ be mutated). Allowing write access to variables in a closed-over lexical scope outside the innermost scope wouldn't hurt because: 1) if you need it, you can already do it -- just practice some cumbersome tricks make suitable arrangements (e.g. the classical accumulator example uses an array to hold the counter value instead of binding it directly to the free variable; 2) if you don't need or understand it, you don't have to use it; 3) and at least in function instances: if you accidentally do, it'll change the bindings within your closure only which is definitely less dangerous than mutating objects that are bound inside the closure. It must be noted, however, that such behaviour would change the way of hiding nested variable names: Now it's safe (though maybe lexically confusing) to use the same variable names in inner functions. This could happen with common names for temporary variables like "i", "x", "y". On the other hand, one could introduce a way to declare variables from global scope or from local scope, with default from lexical scope. (If you want to explicitly hide an outer binding, you'd declare "local foo", for example. You can already do "global foo".) > I see what you are saying (I think), but I think I'd still like a > full anonymous def, whatever adapter you come up with. And I prefer > to be persuaded ;-) I elaborated on this one in a post a few days ago. Indeed, it is mostly a minor issue that _can_ be worked around(1). The problem is that it eventually becomes irritating, when repeated all the time, to name functions even if the name isn't used elsewhere. It also creates an implicit dependency from the function call (one of whose arguments points to the once-named function) to the once-named function. That is, when you refactor some of your code, you must keep two things paired all the time in your cut+paste maneuvers. br, S (1) Everything can be worked around. In contrast: you can work around the lack of a syntactic language by typing in machine code manually. Sound stupid? Yes, it was done decades ago. How about using C to write a "shell script" equivalent that you need, as a workaround to the problem of lacking a shell? Stupid? Yes, but less -- it's been done. How about writing callbacks by passing in a function pointer and a data pointer, if you don't want to use a language like Python that automates that task for you? Stupid? Yes, but not much -- it's been done all the time. How about implementing an _anonymous_ function by naming it, if you can't do it otherwise? -- http://mail.python.org/mailman/listinfo/python-list