On Saturday 25 October 2003 04:29 pm, Neal Norwitz wrote:
On Sat, Oct 25, 2003 at 04:03:17PM +0200, Alex Martelli wrote:
Yes! If the compiler needs to be aware of global assignments (which IS a good idea) we can do so by either introducing a new "operator keyword"
One thing that I've always wondered about, why can't one do:
def reset_foo(): global foo = [] # declare as global and do assignment
As Alex pointed out in another mail (I'm paraphrasing liberally): redundancy is bad. By having to declare foo as global, there's a guaranteed redundancy of the variable when foo is also assigned.
I don't know if this solution would make Alex dislike global less. But it changes global to look more like a statement, rather than a declaration.
Indeed, you can see 'global', in this case, as a kind of "operator keyword", modifying the scope of foo in an assignment statement. I really have two separate peeves against global (not necessarily in order of importance, actually): -- it's the wrong keyword, doesn't really _mean_ "global" -- it's a "declarative statement", the only one in Python (ecch) (leading to weird uncertainty about where it can be placed) -- "side-effect" assignment to globals, such as in def, class &c statements, is quite tricky and error-prone, not useful Well, OK, _three_ peeves... usual Spanish Inquisition issue...:-) Your proposal is quite satisfactory wrt solving the second issue, from my viewpoint. It would still create a unique-in-Python construct, but not (IMHO) a problematic one. As you point out, it _would_ be more concise than having to separately [a] say foo is global then [b] assign something. It would solve any uncertainty regarding placement of 'global', and syntactically impede using global variables in "rebinding as side-effect" cases such as def &c, so the third issue disappears. The first issue, of course, is untouched:-). It can't be touched without choosing a different keyword, anyway. So, with 2 resolutions out of 3, I do like your idea. However, I don't think we can get there from here. Guido has explained that the parser must be able to understand a statement that starts with 'global' without look-ahead; I don't know if it can keep accepting, for bw compat and with a warning, the old global xx while also accepting the new and improved global xx = 23 But perhaps it's not quite as hard as the "global.xx = 23" would be. I find Python's parser too murky & mysterious to feel sure. Other side issues: if you rebind a module-level xx in half a dozen places in your function f, right now you only need ONE "global xx" somewhere in f (just about anywhere); with your proposal, you'd need to flag "global xx = 23" at each of the several assignments to that xx. Now, _that suits me just fine_: indeed, I LOVE the fact that a bare "xx = 23" is KNOWN to set a local, and you don't have to look all over the place for declarative statements that might affect its semantics (hmmm, perhaps a 4th peeve vs global, but I see it as part and parcel of peeve #2:-). But globals-lovers might complain that it makes using globals a TAD less convenient. (Personally, I would not mind THAT at all, either: if as a result people use 10% fewer globals and replace them with arguments or classes etc, I think that will enhance their programs anyway;-). So -- +1, even though we may need a different keyword to solve [a] the problem of getting there from here AND [b] my peeve #1 ...:-). Alex