[Tutor] question about importing threads

ALAN GAULD alan.gauld at btinternet.com
Sat Feb 10 01:47:16 CET 2007


> i have two classes in my program that use a global object 
> that is a socket connection.
> ... code snipped
> is there something tricky about passing this as a global object to 
> different modules that would need to use it?


Whiler its possible to use a global in this way its usually better to 
avoid global objects in a reusable component since otherwise it 
might clash with another global that the reuser already has. Its much 
better to use a parameter which can be provided by the user of the 
classes. In this case the socklet becomesc a parameter.

A good place to put this parameter would be the init method of both 
your classes, where they would store a reference to it as an internal 
attribute. (remember that in Python all attributes are references so if 
you pass the same socket to both constructors both classes will point 
at the same socket).

This approach also allows the user of your classes to suvbstitute 
any socketlike object that they mauy have, even their own bespoke 
version if needed. That greatly increases the flexibility of your code.

> Or does this go along with what you wrote a while back about 
> having classes that depend on each other ?

If you really must use a shared global then I would strongly consider 
putting both classes, the global variable and an initialisation function 
all in a single module. If however tyou can parameterise things as 
described then you need to consider whether anyone would be 
able to (and want to) use either of the classes without the other. 
If you always need them as a pair they still should go in one module, 
otherwise put them in separate modules.

> One runs as a thread, the other responds to gui input.

Does it respond to GUI input or just input? If it can be independant 
of the GUI (and you should really try hard to make it so) then its 
independant and best in its own module. The fact that the other runs 
in a thred is fairly irrelevant to this discussion, the real issue is 
whether it has hard coded dependencies on the other class. For 
example does it instantiate a copy within its methods? (in which 
case you must import the other module/class into this module) And 
more especially does it take an instance as a parameter of a method?
(in which case the *re-user* must import the other module.) In the second 
case I'd say definitely put them in a single module, in the first case 
consider it, but it's not essential.

I hope that makes sense,

Alan G.


On 12/31/06, Alan Gauld <alan.gauld at btinternet.com> wrote:
"shawn bright" <nephish at gmail.com> wrote

> Yes, the thing is getting to be a pain to deal with at this size, i
> am
> in-process of splitting out the classes into their own files.


One thing to watch is that while its easy and tempting to create
one file per class it's often better to keep dependant classes
together.
In other words if class A can only be used together with class B

then it is often better to keep A and B in the same module.
Anyone who needs B can import the module and anyone who
needs A needs B too so it saves them having to import two
modules.

As in all things in programming a little bit of thought is often

better than the first "obvious" strategy. Grady Booch described
the above strategy by saying that "the unit of reuse is the category"
(which in his OO notation was a set of related classes) and in

Python that means the module.

Regards,

Alan G.


_______________________________________________
Tutor maillist  -  Tutor at python.org

http://mail.python.org/mailman/listinfo/tutor









	
	
		
___________________________________________________________ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20070210/ea7a260b/attachment.htm 


More information about the Tutor mailing list