Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #109827 > unrolled thread

the global keyword:

Back to article view | Back to comp.lang.python

Contents

  the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 16:44 -0700
    Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 19:50 -0400
      Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 17:12 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 21:27 -0400
      Re: the global keyword: Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-11 20:15 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-12 14:46 -0400
    Re: the global keyword: MRAB <python@mrabarnett.plus.com> - 2016-06-12 01:09 +0100
      Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 17:13 -0700
        Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-11 20:41 -0700
    Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 21:26 -0400
      Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-12 13:38 +1000
        Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-11 20:48 -0700
          Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-12 11:31 -0700
    Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-12 20:07 +0100
      Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-12 12:25 -0700
        Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-12 22:10 +0100
          Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-19 16:35 +0200
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-19 22:20 +0100
              Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-20 13:14 +0200
                Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-20 22:15 +1000
                  Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-20 15:04 +0200
                  Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-20 09:29 -0400
                    Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-21 00:53 +1000
                      Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-21 10:08 +0200
                        Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-21 11:41 +0100
                          Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-21 13:01 +0200
          Re: the global keyword: Joel Goldstick <joel.goldstick@gmail.com> - 2016-06-19 13:16 -0400
            Re: the global keyword: Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-19 22:50 -0700
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-20 11:21 +0100
              Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-20 22:03 +1000
      Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 10:04 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-21 13:15 -0400
          Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 15:20 -0700
            Re: the global keyword: Chris Angelico <rosuav@gmail.com> - 2016-06-22 08:32 +1000
              Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 16:43 -0700
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-22 00:15 +0100
              Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 17:24 -0700
                Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-22 10:24 +0100
                  Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-24 11:00 +1000
                    Re: the global keyword: Chris Angelico <rosuav@gmail.com> - 2016-06-24 11:19 +1000
                    Re: the global keyword: eryk sun <eryksun@gmail.com> - 2016-06-24 02:19 +0000
            Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 16:50 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#110194

Op 20-06-16 om 14:15 schreef Steven D'Aprano:
> On Mon, 20 Jun 2016 09:14 pm, Antoon Pardon wrote:
>
>> Op 19-06-16 om 23:20 schreef BartC:
>>> On 19/06/2016 15:35, Antoon Pardon wrote:
>>>> Op 12-06-16 om 23:10 schreef BartC:
>>>>> On 12/06/2016 20:25, Ned Batchelder wrote:
>>>>>>   Just as here there is no link between x
>>>>>> and y:
>>>>>>
>>>>>>     x = 12
>>>>>>     y = x
>>>>> (And that's a good illustration of why 'y' isn't a name reference to
>>>>> 'x', referring to the "...ducks limp" thread. But best not to rake
>>>>> it up again...)
>>>>>
>>>> I find this rather inaccurate reference to what your opposition is
>>>> supposed to have states together with the remark best not to rake
>>>> this up again, rather disingenuous
>>>>
>>>
>>> Sorry, haven't been able to parse that.
>>>
>>> What is inaccurate? What am I supposed to be opposed to? And why is it
>>> disingenuous? The original thread is still open to posts AFAIK if
>>> someone wants to discuss it further.
>> You are denying a position above. So you oppose the position being denied.
>> However noone defended the position you denied. 
> I'm sorry Antoon, Bart only paid for the ten minute argument.
>
> Bart didn't say anyone had defended it. He made an observation:
>
> "that's a good illustration of why 'y' isn't a name reference to 'x'"
>
> which is factually correct. And this does refer to the "ducks limp" thread.
> Nothing he said was wrong or objectionable, and he didn't imply that anyone
> was taking the opposite position.

If you mean the literal logical implication you are correct. But there is
of course also the implicature. And his ending with "Best not to rake this
up again" is a strong indication he was aware of the implicature.

Because why is there a need to mention that one thing is a good illustration
of something not being the case, unless people have been stating the opposite?
Why should he be raking things up, if he is not stating something that is
opposed by others?

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#110196

On Mon, Jun 20, 2016, at 08:15, Steven D'Aprano wrote:
> Bart didn't say anyone had defended it. He made an observation:
> 
> "that's a good illustration of why 'y' isn't a name reference to 'x'"
> 
> which is factually correct. And this does refer to the "ducks limp"
> thread.

Except it doesn't. Because no-one on that thread made the claim that it
is. There's absolutely nothing in the thread (except maybe earlier
instances of him and you misrepresenting others' claims) about 'y' being
a name reference to 'x', so there's nothing in that thread for it to
reasonably refer to.

> Nothing he said was wrong or objectionable, and he didn't imply that
> anyone was taking the opposite position.

Nonsense.

[toc] | [prev] | [next] | [standalone]

#110203

On Mon, 20 Jun 2016 11:29 pm, Random832 wrote:

> On Mon, Jun 20, 2016, at 08:15, Steven D'Aprano wrote:
>> Bart didn't say anyone had defended it. He made an observation:
>> 
>> "that's a good illustration of why 'y' isn't a name reference to 'x'"
>> 
>> which is factually correct. And this does refer to the "ducks limp"
>> thread.
> 
> Except it doesn't. Because no-one on that thread made the claim that it
> is. There's absolutely nothing in the thread (except maybe earlier
> instances of him and you misrepresenting others' claims) about 'y' being
> a name reference to 'x', so there's nothing in that thread for it to
> reasonably refer to.

The thread is a discussion about name binding and references. And what do
you know, the hypothetical "name y is a reference to name x" is, amazingly,
about name binding and references! Hence the connection between the two.

You know, there's not actually a rule or law that says you have to
automatically take the contrary position to everything I say.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#110220

Op 20-06-16 om 16:53 schreef Steven D'Aprano:
> On Mon, 20 Jun 2016 11:29 pm, Random832 wrote:
>
>> On Mon, Jun 20, 2016, at 08:15, Steven D'Aprano wrote:
>>> Bart didn't say anyone had defended it. He made an observation:
>>>
>>> "that's a good illustration of why 'y' isn't a name reference to 'x'"
>>>
>>> which is factually correct. And this does refer to the "ducks limp"
>>> thread.
>> Except it doesn't. Because no-one on that thread made the claim that it
>> is. There's absolutely nothing in the thread (except maybe earlier
>> instances of him and you misrepresenting others' claims) about 'y' being
>> a name reference to 'x', so there's nothing in that thread for it to
>> reasonably refer to.
> The thread is a discussion about name binding and references. And what do
> you know, the hypothetical "name y is a reference to name x" is, amazingly,
> about name binding and references! Hence the connection between the two.

But being about name bindings and reference doesn't imply it is about
name references.

> You know, there's not actually a rule or law that says you have to
> automatically take the contrary position to everything I say.

There is also not a rule of law that says you have to automatically introduce
semantic games into the discussion when someone else might have a point.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#110224

On 21/06/2016 09:08, Antoon Pardon wrote:
> Op 20-06-16 om 16:53 schreef Steven D'Aprano:

>> You know, there's not actually a rule or law that says you have to
>> automatically take the contrary position to everything I say.
>
> There is also not a rule of law that says you have to automatically introduce
> semantic games into the discussion when someone else might have a point.

Glancing at the ducks limp thread again (starting 3-Jun-2016), it seems 
it was you trying to persuade me that (1) the name references I'd 
implemented (and which allowed me to do extra things that Python 
couldn't) weren't name references at all; (2) that Python really did 
have name references when you tried hard enough to emulate them.

What sort of semantic games were those then?


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#110226

Op 21-06-16 om 12:41 schreef BartC:
> On 21/06/2016 09:08, Antoon Pardon wrote:
>> Op 20-06-16 om 16:53 schreef Steven D'Aprano:
>
>>> You know, there's not actually a rule or law that says you have to
>>> automatically take the contrary position to everything I say.
>>
>> There is also not a rule of law that says you have to automatically
>> introduce
>> semantic games into the discussion when someone else might have a point.
>
> Glancing at the ducks limp thread again (starting 3-Jun-2016), it
> seems it was you trying to persuade me that (1) the name references
> I'd implemented (and which allowed me to do extra things that Python
> couldn't) weren't name references at all; (2) that Python really did
> have name references when you tried hard enough to emulate them.
>
> What sort of semantic games were those then?

If you can't stop yourself from raking that thread up again.
Do it in the thread itself. If you do, could you start with
pointing out where I write about "name references". I don't
recall having used that.

-- 
Antoon Pardon.

[toc] | [prev] | [next] | [standalone]

#110149

On Sun, Jun 19, 2016 at 10:35 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 12-06-16 om 23:10 schreef BartC:
>> On 12/06/2016 20:25, Ned Batchelder wrote:
>>>   Just as here there is no link between x
>>> and y:
>>>
>>>     x = 12
>>>     y = x
>>
>> (And that's a good illustration of why 'y' isn't a name reference to 'x', referring to the "...ducks limp" thread. But best not to rake it up again...)
>>
> I find this rather inaccurate reference to what your opposition is
> supposed to have states together with the remark best not to rake
> this up again, rather disingenuous
> --
> https://mail.python.org/mailman/listinfo/python-list

People who understand global variables generally avoid using them at
all costs.  People who don't understand why globals create problems
seem to want to use them, and then become baffled at the problems they
cause.  If you are learning python, very very low on your list of
things to learn is global variables.

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays

[toc] | [prev] | [next] | [standalone]

#110175

On Monday, June 20, 2016 at 5:16:50 AM UTC+12, Joel Goldstick wrote:
> People who understand global variables generally avoid using them at
> all costs.

I use them occasionally.

> People who don't understand why globals create problems
> seem to want to use them, and then become baffled at the problems they
> cause.

Haven’t encountered any “baffling” problems with them yet.

> If you are learning python, very very low on your list of
> things to learn is global variables.

Probably fair comment.

“nonlocal” is much more fun. ;)

[toc] | [prev] | [next] | [standalone]

#110189

On 19/06/2016 18:16, Joel Goldstick wrote:

> People who understand global variables generally avoid using them at
> all costs.

Then perhaps they don't understand that in Python, top-level functions, 
classes and imports are also globals.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110192

On Mon, 20 Jun 2016 08:21 pm, BartC wrote:

> On 19/06/2016 18:16, Joel Goldstick wrote:
> 
>> People who understand global variables generally avoid using them at
>> all costs.
> 
> Then perhaps they don't understand that in Python, top-level functions,
> classes and imports are also globals.

But not global *variables*. They are generally used as per-module global
*constants*, or at least near-constants.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#110246

On Sunday, June 12, 2016 at 2:08:01 PM UTC-5, BartC wrote:
> Anyway, it shows Python doesn't have true cross-module globals.

BS! You can inject symbols into sys.modules and achieve a
true global.

    ## BEGIN: INTERACTIVE SESSION ##
    py> import sys
    py> def foo():
    ...     print 'My name is foo'
    py> sys.modules['__builtin__'].__dict__['foo_func'] = foo
    py> foo_func()
    My name is foo
    ## END: INTERACTIVE SESSION ##

[toc] | [prev] | [next] | [standalone]

#110249

On Tue, Jun 21, 2016, at 13:04, Rick Johnson wrote:
> On Sunday, June 12, 2016 at 2:08:01 PM UTC-5, BartC wrote:
> > Anyway, it shows Python doesn't have true cross-module globals.
> 
> BS! You can inject symbols into sys.modules and achieve a
> true global.

You can put a function or constant there, sure. But if you're using it
as a variable, you'd have to do that *every* time (in which case what's
the point) because reassigning to a builtin by name won't reassign the
builtin, it'll create a new variable in the current context.

[toc] | [prev] | [next] | [standalone]

#110270

On Tuesday, June 21, 2016 at 12:15:38 PM UTC-5, Random832 wrote:
> You can put a function or constant there, sure. But if
> you're using it as a variable, you'd have to do that
> *every* time (in which case what's the point) 

Well, since the term "variable" has been so abused, using it
in such a narrowly defined manner here creates a high
probability of starting a semantics flame-war. (c) python-list

Depending on the specific inputs, the "data a variable
symbol is attached to" may indeed remain static throughout
the entire life of the program -- Hmmm -- in that case,
should we still call it a variable? I suppose it's a matter
of deciding if reality defines a variable, or if programmer
intent defines a variable.

Metaphysical musings aside, i get your point. O:-).

> because reassigning to a builtin by name won't reassign
> the builtin, it'll create a new variable in the current
> context.

True. As can be demonstrated with this interactive session.

    py> import sys
    py> def foo():
    ...     print 'My name is Foo!'
    py> sys.modules['__builtin__'].__dict__['foo_func'] = foo
    py> foo()
    My name is Foo!
    py> foo = 'bar'
    py> foo
    'bar'
    py> sys.modules['__builtin__'].__dict__['foo_func']
    <function foo at 0x02810330>

Storing dynamic data to global space is almost always
foolish, and I'm a fan of name spaces. But i did not
recommend such foolish action, i was merely replying to the
assertion that "Python does have real globals". She does,
you just have look under the tail! 

  (sexual identity yet to be determined)

Besides, Python's global statement is misleading to noobs.
It's unfortunate that Python did not inject a symbol to
represent the module level space. Something like "M" or
"mod", or my personal favorite "MSFL"! (ModuleSpaceForLife)
Then one could have added module-level symbols without all
the semantic hubbub.

    MSFL.foo = 0
    
    def iter_foo():
        MSFL.foo += 1

Heck, when i see the global statement in Python code, i
immediately pinch my nose, and run away. There may be
legitimate uses for the global statement, but i've yet to
see them.

[toc] | [prev] | [next] | [standalone]

#110271

On Wed, Jun 22, 2016 at 8:20 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Then one could have added module-level symbols without all
> the semantic hubbub.
>
>     MSFL.foo = 0
>
>     def iter_foo():
>         MSFL.foo += 1
>

And don't forget that you would need to call this function as
MSFL.iter_foo(). Module-level functions are globals too.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110273

On Tuesday, June 21, 2016 at 5:32:43 PM UTC-5, Chris Angelico wrote:
> On Wed, Jun 22, 2016 at 8:20 AM, Rick Johnson:
> > Then one could have added module-level symbols without all
> > the semantic hubbub.
> >
> >     MSFL.foo = 0
> >
> >     def iter_foo():
> >         MSFL.foo += 1
> >
> 
> And don't forget that you would need to call this function as
> MSFL.iter_foo(). Module-level functions are globals too.

That's true, you got me :-). A better implementation would
be to only require the "resolution to module level" from
*WITHIN* foreign scopes. Which would remove the redundancy of
the top-level assignment/access. 

Here is a new version

    modglo = 0
    def incr_modglo():
        MSFL.modglo += 1
    incr_modglo()
    print modglo

...as opposed to the neo-classical Python way of:

    modglo = 0
    def incr_modglo():
        global modglo
        modglo += 1
    incr_modglo()
    print modglo

...which is implementing an antiquated quasi-state-machine
pattern. Yuck!

[toc] | [prev] | [next] | [standalone]

#110272

On 21/06/2016 23:20, Rick Johnson wrote:
> On Tuesday, June 21, 2016 at 12:15:38 PM UTC-5, Random832 wrote:

> Storing dynamic data to global space is almost always
> foolish, and I'm a fan of name spaces. But i did not
> recommend such foolish action, i was merely replying to the
> assertion that "Python does have real globals". She does,
> you just have look under the tail!

How would you use this idea to solve the OP's problem?

So, module M contains a top-variable G.

Module A imports M, and wants to access the identical variable G, 
without having to write it as M.G.

Assignments (not just in-place mods) to G in M will be reflected in A's 
G, and vice versa.

I tried using your method but it didn't work:

--------------------------------
M.py:
--------------------------------
  G = 5

  print ("M:G=",G)

  def F():
      global G
      G = 44
      print ("M.F:G=",G)
--------------------------------

--------------------------------
A.py (main module):
--------------------------------
import sys
sys.modules['__builtin__'].__dict__['G']=8888
import M

print ("G=",G)
M.F()
print ("G=",G)
--------------------------------

Output of running A.py:

('M:G=', 5)
('G=', 8888)
('M.F:G=', 44)
('G=', 8888)

Using A.G in A.py instead, I get the correct output (values of 5,5,44,44 
for G).


 > i was merely replying to the
 > assertion that "Python does have real globals". She does,
 > you just have look under the tail!

You shouldn't need to do that (what looks like abusing the built-in 
namespace common to all modules). There is also the problem of 
inadvertently injecting a 'global' name that will clash with the 
internal module-scope names in some modules that are not intended to be 
exported.

The 'from' mechanism deals with that, by creating an alias to the 
/value/ of an exported name without affecting identical names in other 
modules, but it has the problem of not being an alias for the name itself.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110275

On Tuesday, June 21, 2016 at 6:16:09 PM UTC-5, BartC wrote:
> On 21/06/2016 23:20, Rick Johnson wrote:
> > On Tuesday, June 21, 2016 at 12:15:38 PM UTC-5, Random832 wrote:
> 
> > Storing dynamic data to global space is almost always
> > foolish, and I'm a fan of name spaces. But i did not
> > recommend such foolish action, i was merely replying to the
> > assertion that "Python does have real globals". She does,
> > you just have look under the tail!
> 
> How would you use this idea to solve the OP's problem?

I never intended to solve the OP's problem, i was just
replying to an unfounded assertion. But since you asked, i
will.

> I tried using your method but it didn't work:

Of course not, the code is absurd. Here is one way (ugly).

    ============================================================
     MODULE A.py
    ============================================================
    """A long long time ago, in a galaxy far away..."""
    import sys
    import B
    sys.modules['__builtin__'].__dict__['BDFL'] = "GvR"
    print sys.modules['__builtin__'].__dict__['BDFL']
    B.attack()
    print sys.modules['__builtin__'].__dict__['BDFL']
    
    ============================================================
     MODULE B.py
    ============================================================
    """Module Episode B: Attack of the Rick!"""
    import sys
    
    def attack():
        sys.modules['__builtin__'].__dict__['BDFL'] = 'Rick'
    
    ============================================================
     OUTPUT FROM A.py    
    ============================================================
    GvR
    Rick
    
Of course, nobody wants to write that much boiler plate over
and over again. So if you search the archives for this string:

  PyModule(G.py): Now Python has REAL globals -- and their
  scoped to boot!
  
(Kindly ignore the misspelling of "they're")
  
...you'll find a thread i authored, that includes an object
exposing a global namespace named "G". Details of how to
inject the symbol G are included. After you have this module
installed, you can write the aforementioned code in a much
simplier form:

    ============================================================
     MODULE A.py
    ============================================================
    """A long long time ago, in a galaxy far away..."""
    import sys
    import B
    G.BDFL = "GvR"
    print G.BDFL
    B.attack()
    print G.BDFL
    
    ============================================================
     MODULE B.py
    ============================================================
    """Module Episode B: Attack of the Rick!"""
    import sys
    
    def attack():
        G.BDFL = 'Rick'

Sweet!

[toc] | [prev] | [next] | [standalone]

#110309

On 22/06/2016 01:24, Rick Johnson wrote:
> On Tuesday, June 21, 2016 at 6:16:09 PM UTC-5, BartC wrote:

>> I tried using your method but it didn't work:

> ...you'll find a thread i authored, that includes an object
> exposing a global namespace named "G". Details of how to
> inject the symbol G are included. After you have this module
> installed,

Oh, after you have that installed. Naturally I skipped straight to your 
code and got:

  NameError: global name 'G' is not defined

>     G.BDFL = "GvR"

But even if it worked, I don't think this two-parter counts as a 'global 
variable' as it is understood. I might as well just create my own G 
module containing:

     BDFL="GvR"

and import it in both A and B. Then I can also write G.BDFL in those 
modules. But remember the point was avoid having to write Test.test_var.

(Perhaps your method dispenses with having to create such a module and 
to have to explicitly import it into each module.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110445

On Wed, 22 Jun 2016 07:24 pm, BartC wrote:

[...]
> But even if it worked, I don't think this two-parter counts as a 'global
> variable' as it is understood. I might as well just create my own G
> module containing:
> 
>      BDFL="GvR"
> 
> and import it in both A and B. Then I can also write G.BDFL in those
> modules. But remember the point was avoid having to write Test.test_var.

The question "Does Python have global variables?" depends on what you mean
by "global variable". That makes it a dispute about definitions, and we
know how they go:

http://lesswrong.com/lw/np/disputing_definitions/


So what do *I* mean by global variables?

To me, a global variable is a variable which is scoped to a level wider than
any single function, i.e. module scope, or whole-application scope. That
is, the variable must be visible to more than one function, or more than
one module.

But further, you must be able to *assign* to that variable with a simple
assignment, without explicitly prefixing the variable with a namespace:

foo = 1

It is okay if you have to declare that the variable is global before
assigning to it.

So to me, Python has module globals, because you can have two functions in
the one module which both assign to the same variable:

def spam():
    global x
    x = 1

def ham():
    global x
    x = 2

x is a global variable. But Python *doesn't* have application-wide globals,
because although you can access a variable across multiple modules at the
same time, you cannot do so without using the fully-qualified name module.x
rather than just x.

(To be precise, for the builtins module specifically, you can *read* the
value of the variable using just x, but you cannot *assign* to it unless
you use the fully-qualified name builtins.x.)


If Rick wishes to argue for a different definition of "global variable",
Rick should explain what his definition is, and why we should prefer it to
mine.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#110446

On Fri, Jun 24, 2016 at 11:00 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> To me, a global variable is a variable which is scoped to a level wider than
> any single function, i.e. module scope, or whole-application scope. That
> is, the variable must be visible to more than one function, or more than
> one module.

... and not part of a closure, because they're not global. (I'd also
say "nor part of an object", but objects in Python have attributes
accessed using 'self.', so your other check removes that. But in C++,
that would need to be another criterion.)

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web