[Tutor] quick query relating to globals (I think)

[alan.gauld@bt.com]

>   The reason I say the above is that one and two.py (there 
> are more, about 8 different modules) are mainly classes 
> grouped together that all do different things, 
> but are only called by the main module.  

Yes, that's what I'd expect.

> The object I want them all to have access to is an instance 
> of a class which handles the program's output to the screen.  

OK, That's a fairly common requirement.

> It would be easier in one class to just output something 
> if needed instead of having to be passed the instance of the
> display class or have to return any output to the screen as 
> well as other data.

OK, thus is where if you draw the object model you get a star 
formation with the display in the middle and all the classes 
accessing it, ie having a relationship with it. 

Therefore they should all know about the display(sometimes 
called a view onbject in GUI terms) and use a standard protocol 
to talk to the view. This way you can easily change the view 
from a debugging view to a fastview to a GUIview etc so long 
as you keep the view interface.

Thats what I meant aboutreuse. If you pass the view object
(thing in your case) to reach class constructor you canlater 
use those classes in other projects with a totally diffeent 
view provoided it has the same protocol.

> program I'm writing (happens to be a game) is pretty huge in 
> scope (at least for me, whose largest project to date is 
> 20,000 lines of python

Thats pretty big for Python, certainly way bigger than anything 
I've tackled in Python(3000 lines I think?). It translates to 
something like 100,000 lines of Java or C++!

> the calls to the display module are mainly there for 
> debugging purposes...eventually when most of the 
> logic of the game is working I will use pygame for 
> the UI and any graphic effects

So can you write thing to have the same interface as the 
Pygame stuff thus making it easy to just instantiate a different 
object when debugging versus production use? Thats the whole 
point of OO design, to make that kind of change near transparent...

class Display:
   def f(s): pass

class DebugDisplay(Display):
   def f(s):
      print 'doing f now'
      Display.f(s)

class PyGameDisplay(Display):
   def f(s):
      # various PyGame calls implementing f() behaviour


Now, provided One etc only use the generic Display functions
you can instantiate One, Two etc with:

import display, one, two, ....
activeDisplay = DebugDisplay()
# activeDisplay = PyGameDisplay()

one.One(activeDisplay)
two.Two(activeDisplay)
etc...


And just comment/uncomment the display you want to use...

Just some thoughts,

Alan g.
Author of the 'Learning to Program' web site
http://www.freenetpages.co.uk/hp/alan.gauld