[Python-Dev] replacing 'global'
aleaxit at yahoo.com
Sat Oct 25 11:05:04 EDT 2003
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
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 ...:-).
More information about the Python-Dev