Amended on Tue 03 Feb 2009 01:18 PM (UTC) by First Lensman
Message
It was recommended in a python manual to create a class
that holds global variables. Here is an example that I
culled from a script I wrote to work with the mailman
software package:
class GlobalVariables:
'Class that holds Global Variables'
def __init__(self):
self.LDIR = '/var/lib/mailman/lists'
self.BDIR = '/usr/lib/mailman/bin'
self.THLD = ''
self.MLST = ''
self.EOJ = 0
Then, in the main(), create a varaible using this class:
def main():
global GL
GL = GlobalVariables()
input_list()
process_list()
In any other subroutine that would need access to the
Global Variables, just include the global statement. The
following code is a very simplified version from my script:
def input_list():
global GL
GL.MLST = raw_input("Enter Mailing List: ")
def process_list():
global GL
cfgfile = '/tmp/'+GL.MLST+'_config'
regfile = '/tmp/'+GL.MLST+'_member'
digfile = '/tmp/'+GL.MLST+'_digest'
As you can see, it is much easier to remember the "global GL"
in each routine rather than multiple "global" statements!
Re the disconnection, I am glad the variable is preserved, I was guessing that it did not, and thought that might be Poremenos' problem. In my post I said "This probably means it reinitialises variables.".
Seems it is smarter than that, and my word "probably" was covering the fact that I hadn't actually tested it. :)
Not *pecisely*. In Python you only need the "global" if you are going to assign to the global variable... to read from it, it traverses the scope-hierarchy and discovers the global all by itself..
Ah, strangely, PHP behaves the same way, as I should know, as I do these web pages in it.
Any references to variables in a subroutine are assumed local unless it is told otherwise. I didn't know enough about Python to know that, and my tests were of variables in global scope.
For example, if you do 'Send to Script', I notice that the command that is entered in the send area is interpreted as script-code.. I think it might be executed in the global scope
Yes, that is what it is intended to do, and yes, it executes in global scope.
My tests also indicate that a script function which sets a variable of global scope will set a variable which persists until next time (eg. an alias that sets a variable in a script, and another that tests it).
I am talking Python variables here, not MUSHclient variables.
HOWEVER, there was a problem with syntax errors. I discovered that when Python gave a syntax error it marked the script engine as "disconnected", and that further attempts to script silently failed.
Thus I recently changed it (for Python's benefit really) that if the script engine was in a disconnected state when you went to execute a script it reconnected it. This probably means it reinitialises variables.
However the exact same logic is there for the other script engines.
Thus what will happen, and is probably happening to you, is:
1. You set a variable: /a = 42
2. You make a typing error, and get syntax error
3. You get it right, but the variable has gone: /world.note (a)
Basically this is a development problem. It should go away once the scripts are debugged.
You just have to set them outside of the function... For example, if you do 'Send to Script', I notice that the command that is entered int he send area is interpreted as script-code.. I think it might be executed in the global scope, before any script function is called... YOu can access any variables there in the function, but they may be global and therefore remain... Test it out.
I /do/ know that this works:
/somevar = "Er, hi!"
/world.note(somevar)
So 'somevar' is indeed being set in the global scope...
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.