Re: Python 2.6 Global Variables

2009-10-30 Thread Bruno Desthuilliers

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).

--
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-30 Thread Bruno Desthuilliers

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.
--
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-30 Thread Dave Angel

Gabriel Genellina wrote:
div class=moz-text-flowed style=font-family: -moz-fixedEn Fri, 
30 Oct 2009 00:29:27 -0300, Steven D'Aprano 
st...@remove-this-cybersource.com.au 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

--
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-30 Thread AK Eric
  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 :-P  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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-30 Thread Stephen Hansen
On Fri, Oct 30, 2009 at 9:01 AM, AK Eric warp...@sbcglobal.net wrote:

 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)


It is important to understand how it works-- but only really in that it's
important that people understand how Python handles 'finding' an object when
you specify a name... not understanding this leads lots of people to various
sorts of confusion, especially as they come from other languages. Python
doesn't really have true nested scopes*, it doesn't search up from where you
are to go 'higher' and 'higher' and then check some universal-shared global
scope, etc.

Python has namespaces-- at any given time, there's only three that are
accessible. The local namespace, the global namespace, and the builtin
namespace.

When you reference 'x' in your code, say, as y = x, Python first looks in
the local namespace. Failing to find it there, it looks in the global
namespace-- which is really the module-level namespace. And, finally,
failing that... it looks in the builtin namespace. For, y'know, builtins.

* Okay, in Python 2.1/2.2 there was added a limited level of nested scoping
to Python for functions embedded in other functions; if a name isn't found
in the local scope and the local scope is a nested function, it checks the
locals of the containing function too. This is a great addition, but
actually seems to have inspired people to think Python has a more pervasive
support of dynamic nested scoping going on-- in particular the mythical
'class scope', which it doesn't have.

Now, all that said... one should NOT mess around with __builtin__. You may
break third-party code you use that way, or at least introduce
maintainability nightmares.

In Python things don't live off in the ether, everything lives in an
explicit place. This is a good thing. Messing with __builtin__ and adding
stuff violates this principle. It makes code harder to comprehend by just
looking at a single file-- you can't know where everything is defined that
way, you can't keep your mind local and 'get' what you're working on. 'from
x import *' is a similar problem here, but at least there you have a flag
somewhere in the file saying 'hey, go look over here to maybe find that
var'.

You CAN do it, sure... and there are a some (very, very, very limited!)
use-cases where its even good and the right-thing to do, which is why its
exposed to you to be ABLE to do it, and doesn't have this giant 'DO NOT DO
THIS!' warning in the official docs.  But unless you know you must do it to
get the result you need-- then the answer to, 'Should I use this feature?'
in this case is a resounding no. Use something else instead, even if it
doesn't seem as 'nice' to you (such as import settings; settings.blah
instead of just blah) IMHO. :)

--S
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-30 Thread Aahz
In article 888b5e8f-1be5-4040-bc7a-45c2e1695...@d9g2000prh.googlegroups.com,
AK Eric  warp...@sbcglobal.net 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 (a...@pythoncraft.com)   * 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Bruno Desthuilliers

Ronn Ross a écrit :
(please don't top-post - fixed)

On Oct 28, 2009, at 20:50, mattofak matto...@gmail.com 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?



 Inside the method that you want to use  the var prefix the first
 instance with global. For example: global my_var. Then you can use the
 var like normal in the method. Good luck


Wrong, and wrong again.

1/ you don't have to use the global statement to access a global 
name - only if you plan on rebinding it (which is more often than not a 
bad idea but that's another problem)


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

--
http://mail.python.org/mailman/listinfo/python-list


RE: Python 2.6 Global Variables

2009-10-29 Thread VYAS ASHISH M-NTB837
 
Dear all

How do I write a code that gets executed 'every x' minutes?



I know how to do it 'after x' minutes, I do the following:

def doAtTimerFire(): 
 The things I want to do 'after x' minutes go here. 

And then from main code, I do this:

tmr = threading.Timer(timeInSeconds, doAtTimerFire)
tmr.start()



Please help.

Regards,
Ashish Vyas
 
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Chris Rebert
On Thu, Oct 29, 2009 at 3:25 AM, VYAS ASHISH M-NTB837
ashish.v...@motorola.com wrote:

 Dear all

 How do I write a code that gets executed 'every x' minutes?



 I know how to do it 'after x' minutes, I do the following:

 def doAtTimerFire():
         The things I want to do 'after x' minutes go here. 

 And then from main code, I do this:

 tmr = threading.Timer(timeInSeconds, doAtTimerFire)
 tmr.start()



 Please help.

 Regards,
 Ashish Vyas

Please exercise some basic mailinglist etiquette and start a new
thread, don't hijack an existing one with a completely unrelated
question.
New threads are started by emailing your post to
python-list@python.org rather than replying to a message on an
existing topic.

Regards,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread AK Eric
 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

Not advocating, but it does serve the purpose.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Dave Angel

AK Eric 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

Not advocating, but it does serve the purpose.

  
Good that you're not advocating it, because IMHO it's bad practice to 
have circular import dependencies.  By using the __main__ alias, you 
avoid the worst problems, but that just means the others are more subtle.


You can make it safe, by carefully avoiding certain constructs.  But 
it's still fragile, in that a minor change in one module of the loop can 
cause either an exception or unexpected behavior.


DaveA
--
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread AK Eric
 Good that you're not advocating it, because IMHO it's bad practice to
 have circular import dependencies.  By using the __main__ alias, you
 avoid the worst problems, but that just means the others are more subtle.

I figured I'd get that kind of response, not that it's incorrect ;)
Great power\great responsibility\etc.

As I understand it, when you enter Python statements at the
interactive prompt, it's adding the result directly to ___main___
(which for lack of a better term I like to call 'universal' scope...
rolls off the tongue better than 'doubleunderscore main
doubleunderscore'):

 foo = 23
 import __main__
 print __main__.foo
23

While this might not be the most common way of working for most people
(I'm guessing most folks are in a nice cozy IDE), people working this
way are mucking about in the 'universal' scope without (possibly) even
knowing it.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Benjamin Kaplan
On Thu, Oct 29, 2009 at 7:11 PM, AK Eric warp...@sbcglobal.net wrote:
 Good that you're not advocating it, because IMHO it's bad practice to
 have circular import dependencies.  By using the __main__ alias, you
 avoid the worst problems, but that just means the others are more subtle.

 I figured I'd get that kind of response, not that it's incorrect ;)
 Great power\great responsibility\etc.

 As I understand it, when you enter Python statements at the
 interactive prompt, it's adding the result directly to ___main___
 (which for lack of a better term I like to call 'universal' scope...
 rolls off the tongue better than 'doubleunderscore main
 doubleunderscore'):

 foo = 23
 import __main__
 print __main__.foo
 23

 While this might not be the most common way of working for most people
 (I'm guessing most folks are in a nice cozy IDE), people working this
 way are mucking about in the 'universal' scope without (possibly) even
 knowing it.
 --

Or, you could use any other random module for this like, say, a module
made specifically for this purpose and given a name like config.py
or settings.py or something like that which describes what you're
using it for. You don't have a universal scope- it's the
module-level scope of the script that is actually run (or the
interactive interpreter in this case).
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Steven D'Aprano
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!


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

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

[st...@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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-29 Thread Gabriel Genellina
En Fri, 30 Oct 2009 00:29:27 -0300, Steven D'Aprano  
st...@remove-this-cybersource.com.au 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!

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

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

[st...@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

--
http://mail.python.org/mailman/listinfo/python-list


Python 2.6 Global Variables

2009-10-28 Thread mattofak
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


Re: Python 2.6 Global Variables

2009-10-28 Thread Ronn Ross
Inside the method that you want to use  the var prefix the first  
instance with global. For example: global my_var. Then you can use the  
var like normal in the method. Good luck


On Oct 28, 2009, at 20:50, mattofak matto...@gmail.com 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

--
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-28 Thread Chris Rebert
 On Oct 28, 2009, at 20:50, mattofak matto...@gmail.com 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?

On Wed, Oct 28, 2009 at 6:02 PM, Ronn Ross ronn.r...@gmail.com wrote:
 Inside the method that you want to use  the var prefix the first instance
 with global. For example: global my_var. Then you can use the var like
 normal in the method. Good luck

Note that without a global declaration, functions can still read
global variables and modify the objects associated with them, but will
be unable to re-bind (i.e. reassign) entirely different objects to
global variables; the `global` statement just permits them to rebind
global variables to new values.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Python 2.6 Global Variables

2009-10-28 Thread Benjamin Kaplan
On Wed, Oct 28, 2009 at 8:50 PM, mattofak matto...@gmail.com 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?


Make a separate module with all the config stuff in it, and import
that module everywhere you need it. Just make sure you do import
settings and not from settings import *. The behavior is different.
In the first case, one instance of the module is shared among every
module that imports it, so any changes you make will appear in all
modules. IN the second case, the current values in settings.py are
copied into the local namespace. Changes made in one module won't
appear in the other modules.

 Thanks;
 Matthew Walker
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list