reaching hidden methods + casting

[per9000]

Hi,
can I reach a hidden method when doing ugly inheritance in python?

>>class A:

.... def spin(self, n): print "A", n
....

>>class B:

.... def spin(self, m): print "B", m
....

>>class C(A,B):

.... def spin(self, k): print "C", k
....

>>myC = C()
dir(myC)

['__doc__', '__module__', 'spin']

In f.x. the C-family of languages I guess something like this would
call B.spin:
((B)myC).spin("Lancelot"); // almost forgot the ';'

Please correct me I am wrong (which I likely am) but as I understand
it this example calls the constructor of int instead of casting it,
right?

>>leet = int('1337')
leet

1337

So is there another way of digging into the past of a class? Or can/
should I create constructors for the classes A, B and C that takes
objects of the other classes?

Or should I have thought about getting unique names before I
implemented the ugly inheritance graph?

/Per

--

Per Erik Strandberg
blog: http://www.pererikstrandberg.se/blog/

[Gabriel Genellina]

En Thu, 12 Apr 2007 04:18:19 -0300, per9000 <pe*****@gmail.comescribió:

Hi,
can I reach a hidden method when doing ugly inheritance in python?

>>>class A:

... def spin(self, n): print "A", n
...

>>>class B:

... def spin(self, m): print "B", m
...

>>>class C(A,B):

... def spin(self, k): print "C", k
...

>>>myC = C()
dir(myC)

['__doc__', '__module__', 'spin']

In f.x. the C-family of languages I guess something like this would
call B.spin:
((B)myC).spin("Lancelot"); // almost forgot the ';'

Try this in Python:
B.spin(myC, "Lancelot")

You can't ask the instance for myC.spin because that would retrieve
C.spin; you need B.spin instead. But if you get it this way, it's not
associated to a specific instance, so you must pass myC explicitely
(becoming 'self').

Please correct me I am wrong (which I likely am) but as I understand
it this example calls the constructor of int instead of casting it,
right?

>>>leet = int('1337')
leet

1337

Yes.

So is there another way of digging into the past of a class? Or can/
should I create constructors for the classes A, B and C that takes
objects of the other classes?

No need for that. And usually, that's not what you want either: you're
creating a *different* object that way, not calling a (shadowed) method on
an existing object.

Or should I have thought about getting unique names before I
implemented the ugly inheritance graph?

Perhaps...

--
Gabriel Genellina

[Bruno Desthuilliers]

per9000 a écrit :

Hi,
can I reach a hidden method when doing ugly inheritance in python?

>>>class A:

... def spin(self, n): print "A", n
...

>>>class B:

... def spin(self, m): print "B", m
...

>>>class C(A,B):

... def spin(self, k): print "C", k
...

>>>myC = C()
dir(myC)

['__doc__', '__module__', 'spin']

In f.x. the C-family of languages I guess something like this would
call B.spin:
((B)myC).spin("Lancelot"); // almost forgot the ';'

B.spin(myC, "lancelot")

In Python, the syntax:
some_instance.some_method(param)

is syntactic sugar for
SomeClass.some_method(some_instance, param)

(assuming isinstance(some_instance, SomeClass) == True)

Please correct me I am wrong (which I likely am) but as I understand
it this example calls the constructor of int instead of casting it,
right?

>>>leet = int('1337')
leet

1337

There's nothing like "casting" in Python - it would be meaningless in a
dynamically typed language. The above example does not "cast" a string
to an int, it creates an int - you have two distinct objects, whereas
with casting you have two representations of the same object.

Or should I have thought about getting unique names before I
implemented the ugly inheritance graph?

This is a design question, and we don't have enough context to answer it.

[per9000]

On 12 Apr, 09:42, "Gabriel Genellina" <[e-mail]:

>
<snip>

In f.x. the C-family of languages I guess something like this would
call B.spin:
((B)myC).spin("Lancelot"); // almost forgot the ';'

Try this in Python:
B.spin(myC, "Lancelot")
<snip>

Thanks, that was exactly the insight i needed.

/Per

--

Per Erik Strandberg
blog: http://www.pererikstrandberg.se/blog/