(beginner) question on threads...

[Joal Heagney]

Fred Pacquier wrote:

> Hmm. I was loath to make a fool of myself yet again, but you just offered
> the opportunity for another naive question :-)

*chuckles* You'll find this is THE best newsgroup to ask naive questions
in. The gurus (Tim, Emile and Guido to name a few) don't mind answering
the really interesting questions (Implementation, exotic classes etc.)
people pop up, the intermediates take this as an example of good
behaviour and take care of the medium level questions and then people
like me answer as many newbie questions that they can accuratly field.
The trick is to know when to shut up and let somebody more experienced
field the question. Plus each of us at the just-above neophyte level has
experience in different aspects of python, and how we learnt it - I know
some of the beginner-useful modules (not all) and I'm very good at how
to build python and python extension module rpms.

> I was wondering how people handle this class hierarchy stuff in large
> bodies of code. Right now I load a module in an editor, see it inherits
> from some class in module foo, so I load that in another window. If foo
> inherits some class in bar, I need to look that up too, and so on. I find I
> rather quickly hit the ceiling in my ability for abstraction, and the
> general picture muddies up pretty fast :)

If you look at the standard library, you'll see one of the major
principles of python coding is to keep the inheritance tree as flat as
possible. For example, you have a module A, that imports module B, which
imports module C. Now module A uses a function in module B that comes
from module C. It is better code practice to import module C into module
A and use the function directly, rather than rely on it being included
in module B.

A diagram:

	     module A
(contains all functions in B and C because it)
		|
	     imports B
(which contains all functions in C because it)
		|
	    imports C

A uses B.C.function.
Now if B is altered so that it no longer imports C, A breaks, and you
have to transverse the inheritence tree to find out why.
Alternatively, say B stays the same, but C is altered so that function
is no longer provided. B may not break, but A does. It's simple in this
example to find out what's happening, but in more complex trees, you can
get really tangled.

Instead:
	    module A
(contains all functions in B and C because it)
	|		|
    imports B		and C
(which contains all
functions in C
because it)
	|
    imports C

Instead of A using B.C.function, it now uses C.function directly. B is
altered so that it no longer imports C, A still works. If C breaks in
the second example above, you no longer have to hunt down where the
function came from, you know you got it from C, so you can check it
directly.

> Is there not a better way ? Some tool that will build a picture of a class
> from its code, with all its methods and attributes, inherited or not ?

from pydoc import help
import os
help(os)
class test:
	def __init__(self,blah):
		self.blah = blah
	def afunc(self,values):
		blahblablah
class test2(test):
	def bfunc(self):
		blah-blablabla - blabblah

help(test)

And then the pydoc module supports other objects that let you build
html/txt and output to file.
-- 
      Joal Heagney is: _____           _____
   /\ _     __   __ _    |     | _  ___  |
  /__\|\  ||   ||__ |\  || |___|/_\|___] |
 /    \ \_||__ ||___| \_|! |   |   \   \ !