One Worry for 2.2

Pete Shinners shredwheat at mediaone.net
Wed Jul 18 18:27:16 CEST 2001


i'm excited for the new features coming in 2.2. reading some
release notes, i found a new difference that bothers me.

"""
There's one very specific (and fortunately uncommon) bug that
used to go undetected, but which is now reported as an error:
    class A:
        def foo(self): pass

    class B(A): pass

    class C(A):
        def foo(self):
            B.foo(self)

Here, C.foo wants to call A.foo, but by mistake calls B.foo.
In the old system, because B doesn't define foo, B.foo is
identical to A.foo, so the call would succeed. In the new
system, B.foo is marked as a method requiring a B instance,
and a C is not a B, so the call fails.
"""

now in my mind's understanding of OO, if class B inherits
from class A, then class B has a foo() function. what this
is implying is that only _instances_ of class B have a foo()
function.

i don't really see this as "very specific (and fortunately
uncommon) bug", i see it as the way things are supposed to
work. i can think of several cases where working like this
is entirely less flexible and full of problems. (especially
in the GUI widget department)

is this change implemented because it needs to be?
(ie, the type/class merging doesn't work without it)
or is this change implemented because it was decided
they could add this in?

i really think this sort of change should be 'repealed'
if that is possible. i just see it as a bit worse rather
than a bit better. Being able to do this is what makes OO
work. without it, like is going to be a pain in some
departments.






More information about the Python-list mailing list