[Tutor] question about importing threads
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,
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
> 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
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
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.
Tutor maillist - Tutor at python.org
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tutor