persistant gloabl vars (very newbie) ?

[Stef Mientki]

hi all,

I'm investigating the possibilities to replace MatLab with Python
(+NumPy +SciPy).
I'm a very newbie, I just typed my first characters and calculated the
sum of 2 and 3 in Python.

My application is a Delphi program, for data-acquisition and real-time
data analysis. The real-time analysis is done with MatLab, embedded
through a OLE coupling. I already found PythonforDelphi which probably
helps a lot to make the first steps.

But I'm now stumbled about something very basic, which I don't
understand. The problem might be due to the IDE I use (PyScripter), but
I tried several and they all behave the same. And I expect that the
observed behaviour might be very important notch in my final
application (blockwise, real time interaction).

In MatLab I declare a workspace, in which each variable I declare
is automatically global, and can be reached from all views, i.e. from
the command line interpreter as well as form the OLE environment, no
matter where they are declared.
I try to do something similar in Python:
- I want to run an initialization part just once
- I want to run some testcode often and interactively

So the most simple example:

#Initialization
import time;
A = 5;

#code under test
x=time.time();
# do something time consuming
print 1000*(time.time()-x);

Now if I run the initialization part, manual line by line in the command
line interpreter, I can run the code under test as often as I want.
My real initilization code is much larger and therefor very clumsy to
run line by line in the command line interpreter.

Is there a way to run the initialization code from a script(file) once,
to achieve the same effect ?

thanks,
Stef Mientki

 

[Erik Johnson]

Is there a way to run the initialization code from a script(file) once,
to achieve the same effect ?

Certainly. This is what Python modules are all about. You should probably
read up on those a bit here: http://docs.python.org/tut/node8.html

But briefly, probably what you want to do is put some code in a file, say
init.py:

# init.py
X = 3
Y = 5
# A bunch of other stuff


And then in your main program, execute

from init import *

That will take all the module-scoped variables defined in init.py and place
them in the namespace of the import statement (whcih could be global, the
interactive interpreter, or otherwise)

See also the 'global' statement as it relates to modifying global variables
in an inner scope.

Good luck,
-ej

 

[Piet van Oostrum]

EJ> But briefly, probably what you want to do is put some code in a file, say
EJ> init.py:

EJ> # init.py
EJ> X = 3
EJ> Y = 5
EJ> # A bunch of other stuff

EJ> And then in your main program, execute

EJ> from init import *

EJ> That will take all the module-scoped variables defined in init.py and place
EJ> them in the namespace of the import statement (whcih could be global, the
EJ> interactive interpreter, or otherwise)

This way of saying it is slightly wrong or misleading. It does not place
the global variables of init.py in the importing module in the same way
as most other programming languages use this concept. Rather it makes new
bindings in the importing module with the same names and the same values
as in the original module. So they are new variables with the same values.
If in the importing module e.g. you say X = 4, this will change the value
of X in the importing module, but not in the init module, nor in any
other module that has done 'from init import *'.

If you want that kind of behaviour it is better to use: 'import init' and
refer to the variables as init.X and init.Y so that you can change them.
Whether that is a good idea is another matter.

There are other reasons for not using the from init import * form, as you
might overwrite bindings in the module in an unforseen way. from init
import X,Y explicitely is probably safer. And, by the way, from init import
* can only be used at module level, not in inner namespaces.

 

[Stef Mientki]

other module that has done 'from init import *'.

If you want that kind of behaviour it is better to use: 'import init' and
refer to the variables as init.X and init.Y so that you can change them.
Whether that is a good idea is another matter.

There are other reasons for not using the from init import * form, as you
might overwrite bindings in the module in an unforseen way. from init
import X,Y explicitely is probably safer. And, by the way, from init import
* can only be used at module level, not in inner namespaces.

thank you guys,
but it's still not quit handy

# initialization file (init1.py)
import time;
xx = 44

# main file was
print xx
x=time.time()

# main file should become
print init1.xx
x=init1.time.time()

so even for the "standard" functions like "time" I've to include the
preceeding module "init1" :-(

cheers,
Stef Mientki

 

[Erik Johnson]

but it's still not quit handy

# initialization file (init1.py)
import time;
xx = 44

# main file was
print xx
x=time.time()

# main file should become
print init1.xx
x=init1.time.time()

so even for the "standard" functions like "time" I've to include the
preceeding module "init1" :-(

Ummm... does this help?

/src/python/Foo> cat init.py
#! /usr/local/bin/python

from time import time
xx = 44

/src/python/Foo> python
Python 2.3.4 (#1, Feb 7 2005, 15:50:45)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from init import *
dir() ['__builtins__', '__doc__', '__file__', '__name__', 'time', 'xx']
xx 44
time

time() 1167262478.6845641
xx = 42 # this does not change the init module's value!
import init
init.xx

44

As Piet points out, you get a copy of variables defined in a module when
using the from module import * syntax (as is demonstrated by the assignment
above). (And I stand corrected on the notion that you could execute "from
module import *" in other than module level scope.)

If it is your intention to use those variables defined in init to
communicate with other modules making the same sort of import, then you
probably don't want to use "from module import *" syntax. In that case,
you can import just the module, and make assignments into that module's
namespace. (e.g., init.xx = 3)

If all you care about is getting some "stuff" into your global namespace
in a convenient and repeatable way, then I think what I showed both above
and originally is fine.

-ej

 

[Stef Mientki]

but it's still not quit handy

# initialization file (init1.py)
import time;
xx = 44

# main file was
print xx
x=time.time()

# main file should become
print init1.xx
x=init1.time.time()

so even for the "standard" functions like "time" I've to include the
preceeding module "init1" :-(

Ummm... does this help?

/src/python/Foo> cat init.py
#! /usr/local/bin/python

from time import time
xx = 44

/src/python/Foo> python
Python 2.3.4 (#1, Feb 7 2005, 15:50:45)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from init import *
dir() ['__builtins__', '__doc__', '__file__', '__name__', 'time', 'xx']
xx 44
time

time() 1167262478.6845641
xx = 42 # this does not change the init module's value!
import init
init.xx

44

As Piet points out, you get a copy of variables defined in a module when
using the from module import * syntax (as is demonstrated by the assignment
above). (And I stand corrected on the notion that you could execute "from
module import *" in other than module level scope.)

If it is your intention to use those variables defined in init to
communicate with other modules making the same sort of import, then you
probably don't want to use "from module import *" syntax. In that case,
you can import just the module, and make assignments into that module's
namespace. (e.g., init.xx = 3)

If all you care about is getting some "stuff" into your global namespace
in a convenient and repeatable way, then I think what I showed both above
and originally is fine.

thanks Erik,

I think I'm slowly getting the picture:
always use "import", which is the most unambiguous approach.
Life is sometimes difficult for a MatLab user, see my next post ;-)

Stef