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

Discussion in 'Python' started by seberino@spawar.navy.mil, Aug 5, 2005.

  1. Guest

    I've heard 2 people complain that word 'global' is confusing.

    Perhaps 'modulescope' or 'module' would be better?

    Am I the first peope to have thought of this and suggested it?

    Is this a candidate for Python 3000 yet?

    Chris
     
    , Aug 5, 2005
    #1
    1. Advertising

  2. D H Guest

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

    wrote:
    > I've heard 2 people complain that word 'global' is confusing.
    >
    > Perhaps 'modulescope' or 'module' would be better?
    >
    > Am I the first peope to have thought of this and suggested it?
    >
    > Is this a candidate for Python 3000 yet?


    It is likely that more people would find module or modulescope confusing.

    Plus module has a different customary meaning already:

    import <module>
     
    D H, Aug 6, 2005
    #2
    1. Advertising

  3. Atila Olah Guest

    I think D H is right. Or even if you'd find out that most of the people
    would better like 'modulescope' or 'module', (what is, i think,
    imposible), you'd destroy the backward-compatibility with older
    versions of Puthon if you implement it. But it won't be implemented.
    Trust me.
     
    Atila Olah, Aug 6, 2005
    #3
  4. John Roth Guest

    <> wrote in message
    news:...
    > I've heard 2 people complain that word 'global' is confusing.
    >
    > Perhaps 'modulescope' or 'module' would be better?
    >
    > Am I the first peope to have thought of this and suggested it?
    >
    > Is this a candidate for Python 3000 yet?
    >
    > Chris


    A much better idea would be to fix the underlying
    situation that makes the global statement necessary.

    I doubt if this is going to happen either, though.

    John Roth
    >
     
    John Roth, Aug 6, 2005
    #4
  5. Terry Reedy Guest

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

    <> wrote in message
    news:...
    > I've heard 2 people complain that word 'global' is confusing.


    I did to at first.

    > Perhaps 'modulescope' or 'module' would be better?


    Global is an somewhat short adjective that plausibly becomes a noun when
    pluralized. That is hard to match. I have thought of 'modular' as the
    actual meaning of 'global', but 'modulars' does not sound as good to me.

    > Am I the first peope to have thought of this and suggested it?


    You are the first people I remember making at least the 'modulescope'
    suggestion. Searching the newsgroup archive at Google would make sure ;-).

    > Is this a candidate for Python 3000 yet?


    Unlikely. I suspect that global meaning global to the module (as opposed to
    the collection of modules or compilation units) is established CS usage.

    Terry J. Reedy
     
    Terry Reedy, Aug 6, 2005
    #5
  6. Guest

    I'm not saying 'modulescope' and 'module' are the only alternatives or
    even
    the best anyone can come up with.

    'global' has the connotation of being visible *EVERYWHERE*
    where in Python it is just visible in one module's space.

    Can you think of a better alternative or do you believe
    'global' is the best possible?
     
    , Aug 6, 2005
    #6
  7. Guest

    Python 3000 is not worried about backward compatibility.
    It is worried more about what is *best* and getting it done.
    Trust me.

    Let me ask an academic question....Is 'global' the
    *best* choice of all choices in Webster's dictionary?

    If it is then I'll give up and go home. If not then well.....

    Chris
     
    , Aug 6, 2005
    #7
  8. Guest

    Your solution is the best of them all. However, I don't
    have the foggiest idea how it would be accomplished.

    Are you *sure* you can change design so that there
    is no need for a keyword like 'global'? Please enlighten
    me. I'd really appreciate it.

    Chris
     
    , Aug 6, 2005
    #8
  9. Guest

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

    I appreciate your comments. You give reasons why you
    think 'global' is a good idea.

    Are you sure that 'global' is widely assumed to mean
    global to a *file* in proper CS theory? Coming from C....I assumed
    'global' meant global to ENTIRE EXECUTABLE!?!? You
    even admitted you also thought 'global' was confusing in past!
    So how can you say you think CS community in general won't
    have any problem like we BOTH did????

    Chris
     
    , Aug 6, 2005
    #9
  10. Mike Meyer Guest

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

    "John Roth" <> writes:
    > <> wrote in message
    > news:...
    > 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.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Aug 6, 2005
    #10
  11. Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope'or 'module' better?)

    wrote:

    >I've heard 2 people complain that word 'global' is confusing.
    >
    >Perhaps 'modulescope' or 'module' would be better?
    >
    >Am I the first peope to have thought of this and suggested it?
    >
    >Is this a candidate for Python 3000 yet?
    >
    >Chris
    >
    >
    >

    Hmm.. instead of 'global', how about 'outside' ? It seems a bit more
    intuitive to me because it suggests that you mean, "the variable defined
    outside this scope" or outside any nestedness.

    But then again it could be confused to mean "just one scope above this
    one" which isn't necessarily module scope (nested functions, etc.)...
    still, might be less confusing than 'global'.

    Another alternative to having to say "global var" would be to use some
    sort of indicator that you want the global with each usage, like,
    "global.var" or "outside.var"
     
    Joseph Garvin, Aug 6, 2005
    #11
  12. Terry Reedy Guest

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

    <> wrote in message
    news:...
    > Are you sure


    If I were, I would not have started the statement 'I suspect...'. I do not
    insert such words accidentally.

    TJR
     
    Terry Reedy, Aug 6, 2005
    #12
  13. Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or'module' better?)

    On 5 Aug 2005 21:31:02 -0700, ""
    <> declaimed the following in comp.lang.python:

    > I appreciate your comments. You give reasons why you
    > think 'global' is a good idea.
    >
    > Are you sure that 'global' is widely assumed to mean
    > global to a *file* in proper CS theory? Coming from C....I assumed
    > 'global' meant global to ENTIRE EXECUTABLE!?!? You


    Considering that "global" is only useful within the body of a
    "def" block would seem to imply that it is something special within the
    file and not program-wide...

    If "global" were used at the top of a module, then I could see
    that interpretation. It would be similar to a named COMMON in FORTRAN --

    global x
    equivalent to
    COMMON /X/ x

    {My college FORTRAN IV actually /did/ have a "GLOBAL" statement which
    functioned in just that way: each variable specified became the only
    content of a common block named the same as the variable}

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, Aug 6, 2005
    #13
  14. John Roth Guest

    "Mike Meyer" <> wrote in message
    news:...
    > "John Roth" <> writes:
    >> <> wrote in message
    >> news:...
    >> 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 <> http://www.mired.org/home/mwm/
    > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
    > information.
     
    John Roth, Aug 6, 2005
    #14
  15. Peter Hansen Guest

    Fat and happy Pythonistas (was Re: Replacement for keyword 'global'good idea? ...)

    John Roth wrote:
    > 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.


    And here I thought that was the point of Python 3000. To let the
    community produce a much improved language while avoiding the problems
    caused by too much change occurring while people are trying to get
    useful things done with what the language is _now_. The competition
    (and let's see a description of just what that means, too) probably has
    the dual advantage of newness and a small, hackerish community that is
    more than happy to see rapid and radical change. You're right -- as
    with the stereotypical large/slow vs. small/agile company motif -- that
    smaller and more agile will pass larger and slow "on the outside", but
    you're wrong if you think that means the larger-slower entity should
    drop what it's been doing so well and try to compete entirely on the
    smaller-faster entity's own ground.

    BTW, I think "large and stable" would have been less offensive than "fat
    and happy", but perhaps you meant to imply we're both lazy and
    complacent, rather than just satisfied with something that works and not
    inclined to shoot for moving targets every working day. If so, I'm not
    sure why you'd say that, since the evidence doesn't support it.


    -Peter
     
    Peter Hansen, Aug 6, 2005
    #15
  16. Kay Schluehr Guest

    Proposal: unshadow operator '&'

    wrote:
    > I've heard 2 people complain that word 'global' is confusing.
    >
    > Perhaps 'modulescope' or 'module' would be better?
    >
    > Am I the first peope to have thought of this and suggested it?
    >
    > Is this a candidate for Python 3000 yet?
    >
    > Chris


    Maybe a solution would be best that is able to resolve shadowing of a
    variable in an explicit manner.

    Example. you might have the following nested function:

    x = 0
    def h():
    x = 1 # module scoped x will be shadowed
    def g():
    x = 2 # module scoped x and h's local x will be
    shadowed
    def f():
    print x # printing x defined locally in g
    f()
    g()

    The module level x is always accessible from each inner function using
    the global keyword but it is not possible to access x defined locally
    in h from f.

    Two hypothetical variants using an "unshadow operator" & explicitely:

    x = 0
    def h():
    x = 1
    def g():
    x = 2
    def f():
    print &x # unshadowing x defined in h
    f()
    g()


    x = 0
    def h():
    x = 1
    def g():
    x = 2
    def f():
    print &&x # unshadowing x defined on module level
    f()
    g()

    Since we can always shadow some module scoped variable defining a local
    one we might create a side-effect binding values to the unshadowed
    name:

    x = 0
    def f():
    x = 1
    &x = 7

    >>> f()
    >>> x

    7

    Regards,
    Kay
     
    Kay Schluehr, Aug 6, 2005
    #16
  17. Paolino Guest

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

    wrote:
    > I've heard 2 people complain that word 'global' is confusing.
    >
    > Perhaps 'modulescope' or 'module' would be better?
    >
    > Am I the first peope to have thought of this and suggested it?
    >
    > Is this a candidate for Python 3000 yet?
    >
    > Chris


    I don't think the global keyword is useful actually.

    What's so special in a module nemespace to be priviledged like that.

    The point IMO is accessing names defined somewhere in the enclosing
    namespaces.

    def enclosing():
    var=2
    def enclosed():
    outer var=4

    this is the base of something useful.

    as it is now you neeed

    def enclosing():
    class Var:_=2
    def enclosed():
    Var._=4
    or like others suggested

    def enclosing():
    var=[]
    var[0]=2
    def enclosed():
    var[0]=4
    which is like saying python is not working

    It's ok to mark non locals,but why var=4 is not searched outside and
    var[0]=4 yes?

    I think there is only one or none possible solution to an 'outer'
    statement which is the first bound name matching the 'outer' vars name
    in the chain of enclosing namespaces.

    Why every instance doesn't point to its namespace and every namespace to
    its namespace? Unpythonic ?

    Illogicities to my eyes or at least non-linerities that makes 'global'
    an interesting strangeness to talk about.

    And that namespaces should start being easy sooner or later.


    Regards Paolino





    ___________________________________
    Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
    http://mail.yahoo.it
     
    Paolino, Aug 6, 2005
    #17
  18. Peter Hansen Guest

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

    Paolino wrote:
    > wrote:
    > def enclosing():
    > var=[]
    > var[0]=2
    > def enclosed():
    > var[0]=4
    > which is like saying python is not working
    >
    > It's ok to mark non locals,but why var=4 is not searched outside and
    > var[0]=4 yes?


    Because "var=4" rebinds the name "var", while "var[0]=4" does not. It's
    exactly the same issue with using "global", where you don't need it if
    you aren't rebinding the name.

    (Those who don't understand the difference between "rebinding a name"
    and "modifying an object" will need to figure out that distinction
    before they can participate much in a discussion about Python scopes, I
    think.)

    -Peter
     
    Peter Hansen, Aug 6, 2005
    #18
  19. John Roth Guest

    Re: Fat and happy Pythonistas (was Re: Replacement for keyword 'global' good idea? ...)

    "Peter Hansen" <> wrote in message
    news:...
    > John Roth wrote:
    >> 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.

    >
    > And here I thought that was the point of Python 3000. To let the
    > community produce a much improved language while avoiding the problems
    > caused by too much change occurring while people are trying to get useful
    > things done with what the language is _now_. The competition (and let's
    > see a description of just what that means, too) probably has the dual
    > advantage of newness and a small, hackerish community that is more than
    > happy to see rapid and radical change. You're right -- as with the
    > stereotypical large/slow vs. small/agile company motif -- that smaller and
    > more agile will pass larger and slow "on the outside", but you're wrong if
    > you think that means the larger-slower entity should drop what it's been
    > doing so well and try to compete entirely on the smaller-faster entity's
    > own ground.


    Maybe "fat and happy" wasn't the best choice of words (and maybe
    Extreme Programming wasn't Kent Beck's best choice of words either.)

    However. I see nothing in the existing Python 3000 PEP that does
    anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
    some of it is definitely needed. What I don't see is the inspired leap
    forward that will once again put Python in the forefront rather than
    simply being one choice among many.

    What I want to see in Python 3000 is an AST based language
    that lets the editors do the pretty printing. Do you want automatic
    indenting or would you prefer end statements? It's an editor formatting
    option. The AST neither knows or cares. Don't want to see self?
    Editor formatting option. The AST knows what scope each
    identifier belongs to because it's right there in the text. No need
    for rules that you have to learn, sometimes the hard way.

    Want to see type inference? I haven't a clue how to do it in a
    dynamic language like Python, but an AST based language is a
    perfect test bed for experimentation.

    What's good about other languages? I see very little here
    that is an examination of what Smalltalk, Ruby, Perl, etc.
    seem to have gotten right and could be moved into Python
    to good effect.

    Talk to people who've moved from Python to Ruby, or to
    some other language. Ask them why, if Python is so great,
    what's even greater in that other language. If you still don't
    understand, you might want to read this:

    http://martinfowler.com/bliki/CollectionClosureMethod.html

    Look at Pep 8. It's a compendium of coding standards
    for the standard library. So far, ok. Coding standards
    are generally good. But why does Guido like underscores
    in method names? I know there was (and the accent is
    on the word was) some research, refuted well over a decade
    ago, that mixedCase was hard to read. The fact is that
    _all_ conventions for separating words are hard to read
    until the brain grows new synapses that handle it. Of the
    options, no separation is the hardest to handle. There are
    reasons why ancient texts, which had neither word
    separators nor punctuation, have very contentious translations.

    I find the notion that there should be one obviously right way
    to do something to be a good design principle, so why isn't
    there a single supported GUI library? If I'm over in Java-land,
    just about everything comes with a GUI. Python ships with a
    lot of little demonstration and utility scripts - none of which has
    a GUI.

    Part of the tone here is because of the PEP 208 voting
    process. From day one, I knew it was going to fail.
    Anyone who stood back and looked at the process, rather
    than getting into the detail, knew it was going to fail. There
    was no way that the Python community was going to come
    up with a simple majority in favor of one proposal. None.
    And it was obvious from the start.

    And the sad fact is that a proposition of the form: "We
    want a conditional expression; Guido should pick the
    syntax he finds the least obnoxious and get on with it"
    would have passed. Overwhelmingly.

    I came across a better voting process (Condorcet)
    later. Unfortunately it was later or I would have
    suggested it.

    Why the jihad (and I'm using the word advisedly)
    against the map, filter and reduce operators?
    It seems to be completely irrational from my
    viewpoint. I've seen the arguements, and they
    make no sense.

    > BTW, I think "large and stable" would have been less offensive than "fat
    > and happy", but perhaps you meant to imply we're both lazy and complacent,
    > rather than just satisfied with something that works and not inclined to
    > shoot for moving targets every working day. If so, I'm not sure why you'd
    > say that, since the evidence doesn't support it.


    I'm not suggesting shooting at a moving target. I'm suggesting
    getting the head out of the sand, looking at trends, and figuring
    out the _large_ steps to take next, not the nickle and dime fixups
    that are the only things I see in PEP 3000. (Not to say that some
    of them aren't going to be a lot of work. Some of them are.)

    I came back from Agile2005 last week. The open space session
    on Ruby was maybe 5 times as large as the one on Python. And
    both of them were kind of an afterthought. Look at the OSCon
    blogs. There were a number of hardcore Python people there.
    They couldn't get into Ruby sessions because they were jammed.
    Standing room only.

    There's a report out that the "scripting languages" in general are
    losing mindshare big time in Europe, Africa and the east in general.
    In fact, everywhere except in North America. I'm generally somewhat
    skeptical of these reports unless I can see the methodology, but it's
    definitely a data point.

    Another thing that stands out: the explicit versus dynamic typing debate
    has moved on from program correctness (which is a wash) to
    other areas that explicit (or derived) type information can be used
    for. I see this in PyFit: the languages where explicit type information
    is available by reflection have cleaner implementations. The languages
    with dynamic typing all have to deal with the fact that they can't get
    type information by reflection, and it's a diverse mess.

    The world is moving on, in ways that I think you're not seeing.
    And Python is standing still in many of those same ways.

    John Roth





    John Roth

    >
    >
    > -Peter
     
    John Roth, Aug 6, 2005
    #19
  20. John Roth Guest

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

    "Paolino" <> wrote in message
    news:...
    > wrote:
    >> I've heard 2 people complain that word 'global' is confusing.
    >>
    >> Perhaps 'modulescope' or 'module' would be better?
    >>
    >> Am I the first peope to have thought of this and suggested it?
    >>
    >> Is this a candidate for Python 3000 yet?
    >>
    >> Chris

    >
    > I don't think the global keyword is useful actually.
    >
    > What's so special in a module nemespace to be priviledged like that.


    > The point IMO is accessing names defined somewhere in the enclosing
    > namespaces.


    The issue isn't _accessing_ the module namespace. It's
    binding to identifiers in the module namespace.

    The reason is that _assigning_ to an identifier in a
    function or method makes that identifier local, so
    there needs to be a simply way of saying that you
    want to be able to assign to an identifier in the
    module namespace. (There's already a more
    complicated way: use the global() built-in function.)

    John Roth


    > Regards Paolino
     
    John Roth, Aug 6, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    1,269
    Big K
    Feb 2, 2005
  2. Replies:
    6
    Views:
    486
    Peter Otten
    May 10, 2007
  3. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    376
  4. Dr Mephesto

    App idea, Any idea on implementation?

    Dr Mephesto, Feb 4, 2008, in forum: Python
    Replies:
    3
    Views:
    745
    Dennis Lee Bieber
    Feb 5, 2008
  5. Replies:
    0
    Views:
    653
Loading...

Share This Page