OK, I'm writing a new module, and these are going in. I have better things
to do than remember cryptic conjurements. When I have something
decent, I'll post it. Thanks, Steven.
Jim Roskind (jar@infoseek.com) wrote:
... [excess deleted] ...
: > class a: def m(self): ...
: > class b(a): def m(self): ... parent.m() ... # Calls a.m()
: > class c(b): def m(self): ... parent.m() ... # Calls b.m()
: ...the above could be written:
: > class a: def m(self): ...
: > class b(a): def m(self): ... b.__bases__[0].m() ... # Calls a.m()
: > class c(b): def m(self): ... c.__bases__[0].m() ... # Calls b.m()
: and if you use the above standard construct, the answer to your second
: question:
: > How it (parent) would work with multiple inheritance?
: also falls out. (The other way to look at it is that your "parent"
: extension would really have to be a tuple or array... which is really
: what "__bases__" already is ;-) )
Actually, it only falls out if the method can be found following the
"__bases__[0]" branch of the heirarchy tree. Similar to "depth first",
except this is "depth first, left branch only".
: ...the following will NOT work:
: > class a: def m(self): ...
: > class b(a): def m(self): ... self.__class__.__bases__[0].m() ...
: > class c(b): def m(self): ... self.__class__.__bases__[0].m() ...
I knew that (ask me how).
But I wish to avoid your solution ("b.__bases__...") for two
reasons: it doesn't read well, and it's harder to write modifiable
code.
Modifiable code! Am I harping about that again so soon? Yes.
Here's my story: the fewer places I am required to use an identifier,
the easier I can change my code (and the fewer semantic bugs due to
editing). And in the course of designing a program, I change my code
a lot.
Guido.van.Rossum@cwi.nl wrote:
: BTW, claw@rahul.net wrote:
: > Since LIST is the only mutable sequential type (a hindrance, IMHO),
: > these conversions will permit easy manipulation of elements.
: What exactly do you call a hindrance -- the fact that tuples and
: strings are immutable, the fact that lists mutable, or the fact that
: they share any functionality at all? I can assure you that much
: thought went into this and once you get used to it, it's the only
: way to go. (Oh, and the array module also defines a mutable sequence
: type.)
The first: the fact that tuples and strings are immutable. And I do
believe you, that a lot of thought went into it. I can see it in the
simplicity of the language, and it's capacity to support rather large
programs. Python has features I wish compiled languages had.
However, I think some things are a pain. And these things are
related to sequence types. There are a few functions that require
specific types, such as:
apply(), which requires a tuple. But in constructing an argument
list, I used the more flexible list. Now I have to convert. Why
can't apply take a list also?
hash keys for dictionaries can be tuples, but not lists. Again: I
constructed my key as a list, because it was most suitable, and
now I have to convert.
Yesterday, I needed to duplicate a dictionary. new_dict = dict[:]
won't do it. Is there a good way to do this?
-- Craig Lawson claw@rahul.net