globals accros modules

[alf]

Hi,
executing main.py reulsts in following:


[andy@localhost andy]$ python main.py
Traceback (most recent call last):
File "main.py", line 4, in ?
amodule.f()
File "/raid/home/andy/amodule.py", line 3, in f
print a
NameError: global name 'a' is not defined

How can I have global globals without cyclical import?

A.

 

[Gabriel Genellina]

How can I have global globals without cyclical import?

You can't. Globals are module globals. You need to qualify *which*
module `a` belongs to.

--------------------
amodule.py:
def f():
global a
print a
--------------------
main.py:
import amodule
a=1
amodule.f()

Change a=1 to amodule.a=1
If you find yourself doing tricks with the module globals, think
about redesigning your application.


--
Gabriel Genellina
Softlab SRL






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

 

[Dennis Lee Bieber]

How can I have global globals without cyclical import?

A.

NOTE 1: Python's "global" statement ONLY specifies that the variable
named exists at the module global level AND will be "written to". (You
don't need it to read a module global.)

print a
--------------------
main.py:
import amodule
a=1
amodule.f()

Best means? Put ALL "program globals" into a separate module

-=-=-=-=-=- myglobals.py
pass

-=-=-=-=-=- amodule.py
import myglobals #do NOT use "from myglobals import ...."
def f():
print myglobals.a

-=-=-=-=-=- main.py
import myglobals
import amodule
myglobals.a = 1
amodule.f()


--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[alf]

Change a=1 to amodule.a=1

I have multiple command line programs creating 'a' and amodule using it.
Plus some import sequence dependency. So it would not work. Currently
the solution in amodule is:
import __main__
print __main__.a

If you find yourself doing tricks with the module globals, think about
redesigning your application.

For what I do it is good enough. If I hit the same problem, will
refactor it.

A.

 

[stef]

Change a=1 to amodule.a=1
If you find yourself doing tricks with the module globals, think about
redesigning your application.

Of course I completely agree with you.

But ...
if you're moving from MatLab to Python,
and want to show your collegaes,
with how little effort they can reuse all their existing MatLab routines
in Python,
then the global issue is a real pain !!

You can explain your collegaes, that
- the startindex of arrays changes from 1 to 0
- slices are upto, instead of including the final border
- indention is thé key
And tell them about all beautiful things in Python,
but tell them that they are going to loose all their globals ???

cheers,
Stef Mientki

 

[Bruno Desthuilliers]

stef a écrit :

Of course I completely agree with you.

But ...
if you're moving from MatLab to Python,
and want to show your collegaes,
with how little effort they can reuse all their existing MatLab routines
in Python,
then the global issue is a real pain !!

You can explain your collegaes, that
- the startindex of arrays changes from 1 to 0
- slices are upto, instead of including the final border
- indention is thé key
And tell them about all beautiful things in Python,
but tell them that they are going to loose all their globals ???

It's a feature. Globals are definitively a BadThing(tm).

 

[Stef Mientki]

stef a écrit :

It's a feature. Globals are definitively a BadThing(tm).

 

[Stef Mientki]

stef a écrit :

It's a feature. Globals are definitively a BadThing(tm).

yes, I know, but my audience will accept that only in the long term.

But maybe this idea works:

<file Ugly_MatLab_Globals.py>
global var1
global var2
</file Ugly_MatLab_Globals.py>


<all other py-files in the project>
import Ugly_MatLab_Globals

def some_function():
import Ugly_MatLab_Globals
</all other files in the project>


(btw who owns the BadThing tm ;-)

cheers,
Stef Mientki

 

[Bruno Desthuilliers]

Stef Mientki a écrit :

yes, I know, but my audience will accept that only in the long term.

Unless you clearly explain the benefits... Any code relying on the
existence of a global is:
1/ dependent on the existence of this global
2/ harder to understand

FWIW, I'm currently fixing a simple Delphi program that's using quite a
few globals, and since I'm not familiar with ObjectPascal (my experience
with Pascal boils down to a few cs101 stuff like implementing a linked
list, some 6 or 7 years ago), I'm losing a lost of time with these [bip]
globals...

But maybe this idea works:

<file Ugly_MatLab_Globals.py>
global var1
global var2
</file Ugly_MatLab_Globals.py>

The 'global' statement only makes sens within a function, and it's only
a declaration, not a definition (-> it won't bind the following name by
itself - only tell the interpreter that this name is to be considered as
belonging to the module's namesepace ).

The minimal working example requires that you assign a default value:

# myglobs.py
meaning_of_life = 42

# another.py
import myglobs
print myglobs.meaning_of_life

<all other py-files in the project>
import Ugly_MatLab_Globals

def some_function():
import Ugly_MatLab_Globals

You don't have to reimport it here...

(btw who owns the BadThing tm ;-)

I Do(tm) !-)

 

[Stef Mientki]

Stef Mientki a écrit :

Unless you clearly explain the benefits... Any code relying on the
existence of a global is:
1/ dependent on the existence of this global
2/ harder to understand

And you think physicians will believe that ?
And suppose they believe it, are the willing to stop their research to
rethink and rewrite their code ;-)

FWIW, I'm currently fixing a simple Delphi program that's using quite a
few globals,

Then it was certainly not written by a Delphi-guy ;-)

and since I'm not familiar with ObjectPascal (my experience

with Pascal boils down to a few cs101 stuff like implementing a linked
list, some 6 or 7 years ago), I'm losing a lost of time with these [bip]
globals...

But maybe this idea works:

<file Ugly_MatLab_Globals.py>
global var1
global var2
</file Ugly_MatLab_Globals.py>

The 'global' statement only makes sens within a function, and it's only
a declaration, not a definition (-> it won't bind the following name by
itself - only tell the interpreter that this name is to be considered as
belonging to the module's namesepace ).

The minimal working example requires that you assign a default value:

# myglobs.py
meaning_of_life = 42 thanks for the tip.

# another.py
import myglobs
print myglobs.meaning_of_life

<all other py-files in the project>
import Ugly_MatLab_Globals

def some_function():
import Ugly_MatLab_Globals

You don't have to reimport it here...

Then I miss something:

TEN = 10
TWELVE = 12
def some_function():
global TEN
TEN = 9
TWELVE = 11
print TEN, TWELVE

some_function() #will print 9,11
print TEN, TWELVE #will print 9,12

Or am I mistaken ?

cheers,
Stef Mientki

 

[Gabriel Genellina]

Of course I completely agree with you.

But ...
if you're moving from MatLab to Python,
and want to show your collegaes,
with how little effort they can reuse all their existing MatLab routines
in Python,
then the global issue is a real pain !!

You can explain your collegaes, that
- the startindex of arrays changes from 1 to 0
- slices are upto, instead of including the final border
- indention is thé key
And tell them about all beautiful things in Python,
but tell them that they are going to loose all their globals ???

Yes


--
Gabriel Genellina
Softlab SRL






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

 

[Steve Holden]

Of course I completely agree with you.

But ...
if you're moving from MatLab to Python,
and want to show your collegaes,
with how little effort they can reuse all their existing MatLab routines
in Python,
then the global issue is a real pain !!

You can explain your collegaes, that
- the startindex of arrays changes from 1 to 0
- slices are upto, instead of including the final border
- indention is thé key
And tell them about all beautiful things in Python,
but tell them that they are going to loose all their globals ???

Yup. If they don't tell us how to write programs we won't tell them how
to cure illness. Sounds like a deal to me ...

regards
Steve

 

[Robert Kern]

Bruno Desthuilliers wrote:
And you think physicians will believe that ?
And suppose they believe it, are the willing to stop their research to
rethink and rewrite their code ;-)

If they give a damn about their research, they will. Sloppy, irreproducible lab
technique is not acceptable. Sloppy, impossible-to-verify code shouldn't be, either.

I'd say more, but Greg Wilson has said it better, and has provided course
materials to teach good programming practices to scientists.

http://swc.scipy.org/

Of particular note are his article in the _American Scientist_:

http://www.americanscientist.org/template/AssetDetail/assetid/48548

and his slides from his talk at SciPy '06:

http://www.third-bit.com/lectures/scipy06.pdf

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Dennis Lee Bieber]

Then I miss something:

TEN = 10
TWELVE = 12

A pair of module level names, attached to the integer objects "10"
and "12"

def some_function():
global TEN

Declares that usage of the NAME "TEN" refers to the module level,
and is not local to the function.

TEN = 9

Attaches the module level name to the integer object "9"

TWELVE = 11

Creates a local level name and attaches it to the object "11"

print TEN, TWELVE

Retrieves and prints the objects attached to module level "TEN" and
local level "TWELVE"

some_function() #will print 9,11
print TEN, TWELVE #will print 9,12

Retrieves and prints the objects attached to the module level names.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Bruno Desthuilliers]

Stef Mientki a écrit :

And you think physicians will believe that ?

Aren't physicians supposed to be somewhat cartesians guys ? FWIW,
functional languages are mostly used by peoples with a strong
mathematical background...

And suppose they believe it, are the willing to stop their research to
rethink and rewrite their code ;-)

Not my problem. But anyway, if they really hope to get reliable results,
they'd better have bug-free programs, and using globals not only
potentially introduces subtle bugs, but also makes code hardly
unit-testable...

Then it was certainly not written by a Delphi-guy ;-)

Yes it was. But that does not imply it was written by a competent
Delphi-guy !-)

(snip)

Then I miss something:
Probably

TEN = 10
TWELVE = 12
def some_function():
global TEN
TEN = 9

rebinds the 'global' (well... module) name 'TEN'.

TWELVE = 11

creates a *local* name 'TWELVE' and bind it to integer 11.

print TEN, TWELVE

some_function() #will print 9,11
print TEN, TWELVE #will print 9,12

Or am I mistaken ?

You are.

bruno@bibi playground $ cat myglobals.py
a = None
b = None
bruno@bibi playground $ cat useglobals.py
import myglobals

def test():
myglobals.a = "meaning_of_life"
myglobals.b = 42

print "myglobals.a : ", myglobals.a
print "myglobals.b : ", myglobals.b
test()
print "myglobals.a : ", myglobals.a
print "myglobals.b : ", myglobals.b

bruno@bibi playground $ python useglobals.py
myglobals.a : None
myglobals.b : None
myglobals.a : meaning_of_life
myglobals.b : 42