Imports in python are static, any solution?

[Ravi]

foo.py :

i = 10

def fi():
global i
i = 99

bar.py :

import foo
from foo import i

print i, foo.i
foo.fi()
print i, foo.i

This is problematic. Well I want i to change with foo.fi() .

 

[Luis Alberto Zarrabeitia Gomez]

This is problematic. Well I want i to change with foo.fi() .

You can't. i and foo.i are _different_ variables that just happen to share the
same value initially. What you are observing is no different than

i = 10
j = i
i = 99

print i # prints 99
print j # print 10

May I ask, why is it problematic? You should be avoiding the use of global
variables anyway.

 

[David Stanek]

foo.py :

   i = 10

  def fi():
     global i
     i = 99

bar.py :

   import foo
   from foo import i

   print i, foo.i
   foo.fi()
   print i, foo.i

This is problematic. Well I want i to change with foo.fi() .

Why not only import foo and using foo.i? In fi() when you set i = 99
you are creating a new object called i in foo's namespace.

 

[Dennis Lee Bieber]

foo.py :

i = 10

def fi():
global i
i = 99

bar.py :

import foo
from foo import i

print i, foo.i
foo.fi()
print i, foo.i

This is problematic. Well I want i to change with foo.fi() .

The "i" in bar.py is effectively just a second name bound to the
same object (the integer 10) that is bound to "i" in module foo.

from foo import i

is equivalent to

import foo
i = foo.i

When foo.fi() is executed, it REBINDS foo's "i" to a new object
(integer 99). The "i" in bar does not get rebound and still accesses the
original object.

This behavior is not something dependent upon the behavior of
"import" -- it is the crux of all Python "assignment" behavior.

What you are asking for is the equivalent of expecting

a = 10
b = a
a = 99

to change the value of "b"
--
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/

 

[norseman]

For something like this I generally create a superclass to hold
configuration variables that will change overtime, doing that will save you
from insanity.

Class configVar:

#set initial values
Def __init__(self):
Self.A = 5
Self.B = 10
Self.C = 20


Class myMath(configVars):
def __init__(self):
pass

def SubAandB(self):
return self.A - self.B

def AddCandB(self):
return self.C + self.B

def MultiplyXbyA(self, x):
return self.A * x


m = myMath()
X = m.SubAandB()
Y = m.AddCandB()
Z = m.MultiplyXbyA(32)

Keeps your vars in a safer easier to handle, debug, and change kinda way
Good luck

AJ

-----Original Message-----
From: [email protected]
[mailto[email protected]] On Behalf Of David
Stanek
Sent: Monday, April 13, 2009 12:12 PM
To: Ravi
Cc: (e-mail address removed)
Subject: Re: Imports in python are static, any solution?

foo.py :

i = 10

def fi():
global i
i = 99

bar.py :

import foo
from foo import i

print i, foo.i
foo.fi()
print i, foo.i

This is problematic. Well I want i to change with foo.fi() .

Why not only import foo and using foo.i? In fi() when you set i = 99
you are creating a new object called i in foo's namespace.

===============================

Aj is right. In foo.py there are two definitions for 'i'. The initial
and the replacement initiated by fi(). While initially there is no 'i'
definition in bar itself.

To test, use my changes to bar.py

import foo
#from foo import i

i= foo.i
print i, foo.i
x= foo.fi()
print i, x, foo.i
x= foo.i
print i, x, foo.i

the output will be:
10 10
10 None 99
10 99 99

output is same if you uncomment #from... and comment i=...
The '...import i' creates the "same" var as the i=... in the current run
If you comment out both the from and the i= then the print i will fail
because i has not been defined in current space.
foo.fi() returns None (nothing) per it's definition.
whereas the first foo.i returns the initial i value and the foo.i after
foo.fi() returns the 2nd value, foo's i reset to 99 by fi() inside foo.

Clear as Mud???


Steve

 

[AJ Mayorga]

For something like this I generally create a superclass to hold
configuration variables that will change overtime, doing that will save you
from insanity.

Class configVar:

#set initial values
Def __init__(self):
Self.A = 5
Self.B = 10
Self.C = 20


Class myMath(configVars):
def __init__(self):
pass

def SubAandB(self):
return self.A - self.B

def AddCandB(self):
return self.C + self.B

def MultiplyXbyA(self, x):
return self.A * x


m = myMath()
X = m.SubAandB()
Y = m.AddCandB()
Z = m.MultiplyXbyA(32)

Keeps your vars in a safer easier to handle, debug, and change kinda way
Good luck

AJ

-----Original Message-----
From: [email protected]
[mailto[email protected]] On Behalf Of David
Stanek
Sent: Monday, April 13, 2009 12:12 PM
To: Ravi
Cc: (e-mail address removed)
Subject: Re: Imports in python are static, any solution?

foo.py :

   i = 10

  def fi():
     global i
     i = 99

bar.py :

   import foo
   from foo import i

   print i, foo.i
   foo.fi()
   print i, foo.i

This is problematic. Well I want i to change with foo.fi() .

Why not only import foo and using foo.i? In fi() when you set i = 99
you are creating a new object called i in foo's namespace.

 

[Ravi]

For something like this I generally create a superclass to hold
configuration variables that will change overtime, doing that will save you
from insanity.

Class configVar:

   #set initial values
   Def __init__(self):
           Self.A = 5
           Self.B = 10
           Self.C = 20

Class myMath(configVars):
   def __init__(self):
           pass

   def SubAandB(self):
           return self.A - self.B

   def AddCandB(self):
           return self.C + self.B

   def MultiplyXbyA(self, x):
           return self.A * x

m = myMath()
X = m.SubAandB()
Y = m.AddCandB()
Z = m.MultiplyXbyA(32)

Keeps your vars in a safer easier to handle, debug, and change kinda way
Good luck

AJ

-----Original Message-----
From: [email protected]
[mailto[email protected]] On Behalf Of David
Stanek
Sent: Monday, April 13, 2009 12:12 PM
To: Ravi
Cc: (e-mail address removed)
Subject: Re: Imports in python are static, any solution?

Why not only import foo and using foo.i? In fi() when you set i = 99
you are creating a new object called i in foo's namespace.

===============================

Aj is right. In foo.py there are two definitions for 'i'. The initial
and the replacement initiated by fi(). While initially there is no 'i'
definition in bar itself.

To test, use my changes to bar.py

import foo
#from foo import i

i= foo.i
print i, foo.i
x= foo.fi()
print i, x, foo.i
x= foo.i
print  i, x, foo.i

the output will be:
10 10
10 None 99
10 99 99

output is same if you uncomment #from... and comment i=...
The '...import i' creates the "same" var as the i=... in the current run
If you comment out both the from and the i= then the print i will fail
because i has not been defined in current space.
foo.fi() returns None (nothing) per it's definition.
whereas the first foo.i returns the initial i value and the foo.i after
foo.fi() returns the 2nd value, foo's i reset to 99 by fi() inside foo.

Clear as Mud???

Steve

Yes I find the difference. Thank you all.