Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

John Roth newsgroups at jhrothjr.com
Sat Aug 6 15:37:59 CEST 2005


"Mike Meyer" <mwm at mired.org> wrote in message 
news:861x57wrui.fsf at bhuda.mired.org...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>> <seberino at spawar.navy.mil> wrote in message
>> news:1123270841.195692.21470 at g47g2000cwa.googlegroups.com...
>> A much better idea would be to fix the underlying
>> situation that makes the global statement necessary.
>
> You can't "fix" this. This code (in some python-like langauge that
> isn't python):
>
> x = 23
>
> def fun():
>    x = 25
>    # Rest of code
>
> has two possible interpretations.
>
> Either the occurrence of x in fun references the global, or it
> references a local that shadows the global. There are reasons for
> wanting both behaviors. So you have to have some way to distinguish
> between the two, and you want it to happen per variable, not per
> function. The method with the fewest keywords is to have one be the
> default, and some keyword that triggers the other.
>
> So the only way to remove the global statement would be to have some
> way to mark the other interpretation, with say a "local"
> decleration. I thik that would be much worse than "global". For one
> thing, most variables would be local whether or not they are
> declared. Second, having an indication that you need to check module
> globals in the function is a better than not having that clue there.

You've got half of the answer. The other half is to have the editor/ide
translate the lexical cues into color coding and hide the lexical cues.

It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.

John Roth

>
>        <mike
> -- 
> Mike Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more 
> information. 




More information about the Python-list mailing list