Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python 2.6 Global Variables

Reply
Thread Tools

Python 2.6 Global Variables

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      10-30-2009
On Thu, 29 Oct 2009 10:31:03 -0700, AK Eric wrote:

>> 2/ in Python, "global" really means "module-level" - there's nothing
>> like a "true" global namespace.

>
> Isn't that __main__?


Well there you go, I just learned something new.

I was going to say "No, every module has its own __main__", and say that
the only truly global namespace was builtins, which you really shouldn't
mess with. But then I decided to just try it, and blow me down, it works!


[steve@sylar ~]$ cat set_parrot.py
import __main__
__main__.parrot = "Norwegian Blue"

[steve@sylar ~]$ cat get_parrot.py
import __main__
print __main__.parrot

[steve@sylar ~]$ python
Python 2.5 (r25:51908, Nov 6 2007, 16:54:01)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import set_parrot
>>> import get_parrot

Norwegian Blue


I'm sure there are all sorts of odd problems this would lead to in large
scale code, but it's a neat trick to know.



--
Steven
 
Reply With Quote
 
 
 
 
Gabriel Genellina
Guest
Posts: n/a
 
      10-30-2009
En Fri, 30 Oct 2009 00:29:27 -0300, Steven D'Aprano
<(E-Mail Removed)> escribió:
> On Thu, 29 Oct 2009 10:31:03 -0700, AK Eric wrote:


>>> 2/ in Python, "global" really means "module-level" - there's nothing
>>> like a "true" global namespace.

>>
>> Isn't that __main__?

>
> Well there you go, I just learned something new.
>
> I was going to say "No, every module has its own __main__", and say that
> the only truly global namespace was builtins, which you really shouldn't
> mess with. But then I decided to just try it, and blow me down, it works!
>
> [steve@sylar ~]$ cat set_parrot.py
> import __main__
> __main__.parrot = "Norwegian Blue"
>
> [steve@sylar ~]$ cat get_parrot.py
> import __main__
> print __main__.parrot
>
> [steve@sylar ~]$ python
> Python 2.5 (r25:51908, Nov 6 2007, 16:54:01)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import set_parrot
>>>> import get_parrot

> Norwegian Blue
>
>
> I'm sure there are all sorts of odd problems this would lead to in large
> scale code, but it's a neat trick to know.


It isn't a neat trick anymore once you realize the name '__main__' isn't
special.

Replace __main__ with foo, or config, or whatever, and you get the same
results. Ok, there is a catch: a file with that name must exist, at least
an empty one...

You're just importing the same module from two places; changes done in one
place are reflected in the second place, like with any other object.

--
Gabriel Genellina

 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      10-30-2009
AK Eric a écrit :
>> 2/ in Python, "global" really means "module-level" - there's nothing
>> like a "true" global namespace.

>
> Isn't that __main__?


Nope

>
> import __main__
> __main__.foo = "asdfasdf"
>
> print foo
> # asdfasdf
>
> Not advocating, but it does serve the purpose.


This won't make 'foo' available to other imported modules. Still a
module-level name, and still no "true" global namespace - which FWIW is
a VeryGoodThing(tm).
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      10-30-2009
Bruno Desthuilliers a écrit :
> AK Eric a écrit :
>>> 2/ in Python, "global" really means "module-level" - there's nothing
>>> like a "true" global namespace.

>>
>> Isn't that __main__?

>
> Nope
>
>>
>> import __main__
>> __main__.foo = "asdfasdf"
>>
>> print foo
>> # asdfasdf
>>
>> Not advocating, but it does serve the purpose.

>
> This won't make 'foo' available to other imported modules.


Err, reading Steven and Gabriel's posts, it looks like I'm wrong and
your right. Duh

You really shouldn't show this to childrens.
 
Reply With Quote
 
Dave Angel
Guest
Posts: n/a
 
      10-30-2009
Gabriel Genellina wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">En Fri,
> 30 Oct 2009 00:29:27 -0300, Steven D'Aprano
> <(E-Mail Removed)> escribió:
>> On Thu, 29 Oct 2009 10:31:03 -0700, AK Eric wrote:

>
>>>> 2/ in Python, "global" really means "module-level" - there's nothing
>>>> like a "true" global namespace.
>>> <snip>

> It isn't a neat trick anymore once you realize the name '__main__'
> isn't special.
>
> Replace __main__ with foo, or config, or whatever, and you get the
> same results. Ok, there is a catch: a file with that name must exist,
> at least an empty one...
>
> You're just importing the same module from two places; changes done in
> one place are reflected in the second place, like with any other object.
>

Thanks for saying that.

There are two interrelated advantages to using a separate module for the
purpose.
1) it avoids circular dependency
2) it makes it clear who gets to initialize these "globals"; if this
module doesn't import anything else (other than stdlib stuff), it'll run
to completion before anyone who tries to use these values. So it can
give them all their initial value, and avoid anyone else needing to do
any "existence check" nonsense.

When I've done it, I've called the module globals.py, or flags.py
depending on the primary intent.

DaveA

 
Reply With Quote
 
AK Eric
Guest
Posts: n/a
 
      10-30-2009
> > It isn't a neat trick anymore once you realize the name '__main__'
> > isn't special.

>
> > Replace __main__ with foo, or config, or whatever, and you get the
> > same results. Ok, there is a catch: a file with that name must exist,
> > at least an empty one...


True. I do feel a bit less special now And again, I think there
is a difference from saying you *can* work a certain way, and you
*should* work a certain way. Making a 'global module' you import and
muck with = good. Other ways discussed = bad (for the most part).
But I think it's important to understand the underlying system
especially when one is first learning: I hand a heck of a time having
someone explain this stuff to me when I was learning the basics (and
I'm still figuring it out, even from this thread) and now that I get
how it works (I uh... think) it makes me a stronger scripter. The
common thought seemed to be "you shouldn't do it that way, so I'm not
going to explain it to you" which I've always found quite
frustrating. And along those lines...

Should we start talking about how you can add stuff to __builtin__ and
then it really is exposed to everything? (right, unless I'm missing
some other Python idiom?) Again, *not advocating* in standard
practice, but I think it's important to understand how it works.
(ducks incoming flak)

#---------------------
# moduleA.py
import __builtin__
__builtin__.spam = 42
__builtins__["ham"] = 24

#---------------------
# moduleB.py
# This will fail if moduleA isn't executed first
print spam, ham

>>> import moduleA
>>> import moduleB

42 24

 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      10-30-2009
In article <(E-Mail Removed)>,
AK Eric <(E-Mail Removed)> wrote:
>>
>> 2/ in Python, "global" really means "module-level" - there's nothing
>> like a "true" global namespace.

>
>Isn't that __main__?
>
>import __main__
>__main__.foo = "asdfasdf"
>
>print foo
># asdfasdf


Actually, you're almost right, but it's an even WORSE idea than you
thought:

import __builtin__
__builtin__.foo = 'bar'

Kids, do *NOT* do this at home! The reasons why are left as an exercise
for the reader.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

"You could make Eskimos emigrate to the Sahara by vigorously arguing --
at hundreds of screens' length -- for the wonder, beauty, and utility of
snow." --PNH to rb in r.a.sf.f
 
Reply With Quote
 
Fabio Zadrozny
Guest
Posts: n/a
 
      11-05-2009
On Wed, Oct 28, 2009 at 10:50 PM, mattofak <(E-Mail Removed)> wrote:
> Hi All;
>
> I'm new to Python and moving from C, which is probably a big source of
> my confusion. I'm struggling with something right now though and I
> hope you all can help.
>
> I have a global configuration that I would like all my classes and
> modules to be able to access. What is the correct way to do this?
>
> Thanks;
> Matthew Walker
> --
> http://mail.python.org/mailman/listinfo/python-list
>



I'd usually use the singleton pattern in this case (or you can just
create a class and put things in the class -- and just as a note, I'd
try to avoid declaring anything as global unless really needed).

Cheers,

Fabio
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Initialize global variable before any other global variables jubelbrus C++ 5 07-20-2007 06:38 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 1 10-25-2006 06:50 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 0 10-25-2006 01:04 PM
Global variables on par with ASP's global.asa Wayne ASP .Net 2 11-11-2003 10:58 PM
Global variables - application variables vs include file mark4asp ASP General 1 09-03-2003 01:30 PM



Advertisments