On Wednesday 22 October 2003 00:51, Guido van Rossum wrote: ...
Maybe "global x in f" would work?
Actually, I would rather like to DO AWAY with the anomalous 'global' statement and its weird anomalies such as: x = 23 def f1(u): if u: global x x = 45 def f2(): if 0: global x x = 45 print x f2() print x f1(0) print x "if u:" when u is 0, and "if 0:", should have the same effect to avoid violating the least-astonishment rule -- but when the if's body has a global in it, they don't. Eeek. Plus. EVERY newbie makes the mistake of taking "global" to mean "for ALL modules" rather than "for THIS module", uselessly using global in toplevel, etc. It's a wart and I'd rather work to remove it than to expand it, even though I _would_ like rebindable outers. I'd rather have a special name that means "this module" available for import (yes, I can do that with an import hook today). Say that __this_module__ was deemed acceptable for this. Then, import __this_module__ __this_module__.x = 23 lets me rebind the global-to-this-module variable x without 'global' and its various ills. Yeah, the name isn't _too_ cool. But I like the idea, and when I bounced it experimentally in c.l.py a couple weeks ago the reaction was mildly positive and without flames. Making globals a TAD less handy to rebind from within a function would not be exactly bad, either. (Of course 'global' would stay until 3.0 at least, but having an alternative I could explain it as obsolescent:-). Extending this idea (perhaps overstretching it), some other name "special for import" might indicate outer scopes. Though reserving the whole family of names __outer_<name>__ is probably overdoing it... plus, the object thus 'imported' would not be a module and would raise errors if you tried setattr'ing in it a name that's NOT a local variable of <name> (the import itself would fail if you were not lexically nested inside a function called <name>). Thus this would allow *re-binding* existing local outer names but not *adding* new ones, which feels just fine to me (but maybe not to all). OK, this is 1/4-baked for the closure issue. BUT -- I'd STILL love to gradually ease 'global' out, think the "import __this_module__" idea is 3/4-baked (lacks a good special name...), and would hate to see 'global' gain a new lease of life for sophisticated uses...;-) Alex