[Tutor] question about importing threads
nephish at gmail.com
Sun Feb 11 22:15:45 CET 2007
Yes, Mr Gauld, this is a help. Even though i am still newbie enough to take
some time digesting it.
one last queston. if i have a class that i import as a module, say a script
that emails me when something goes wrong.
so i have a file called my_own_email.py and in it a class called MyOwnEmail.
Now MyOwnEmail needs the smtplib module. Do i need to import it just for the
my_own_email.py or do i need to import it in both that module and my program
that calls it. ?
On 2/9/07, ALAN GAULD <alan.gauld at btinternet.com> wrote:
> > 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<http://uk.rd.yahoo.com/mail/uk/taglines/gmail_com/championships/games/*http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk/>.
> Plus: play games and win prizes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tutor