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.
--------------------
amodule.py:
def f():
global a
print a
--------------------
main.py:
import amodule
a=1
amodule.f()

[Gabriel Genellina]

At Thursday 11/1/2007 01:11, alf wrote:

>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

[alf]

Gabriel Genellina wrote:

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 :

>

>>
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 ???

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

cheers,
Stef Mientki

[Stef Mientki]

Bruno Desthuilliers wrote:

stef a écrit :

>>

>>>
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 ???

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

>cheers,
Stef Mientki

[Stef Mientki]

Bruno Desthuilliers wrote:

stef a écrit :

>>

>>>
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 ???

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 :

Bruno Desthuilliers wrote:

>stef a écrit :

(snip)

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

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]

Bruno Desthuilliers wrote:

Stef Mientki a écrit :

>Bruno Desthuilliers wrote:

>>stef a écrit :

(snip)

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

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

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]

At Thursday 11/1/2007 11:55, stef wrote:

>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]

stef wrote:

>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 ???

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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com

[Robert Kern]

Stef Mientki wrote:

Bruno Desthuilliers wrote:

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

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/tem.../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

[Bruno Desthuilliers]

Stef Mientki a écrit :

Bruno Desthuilliers wrote:

>Stef Mientki a écrit :

>>Bruno Desthuilliers wrote:

stef a écrit :

(snip)

>>>>but tell them that they are going to loose all their globals ???

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

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

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

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

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

(snip)

>>
# 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:

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