RetroSearch Browse

Sat Oct 25 11:05:04 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039501.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039501.html below:

[Python-Dev] replacing 'global'