Python was designed (was Re: Multi-threading in Python vs Java)

[Chris Angelico]

On Sat, Oct 19, 2013 at 8:57 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Wed, 16 Oct 2013 23:49:02 -0700, Peter Cacioppi wrote:
>
>> I don't know if I want to step into the flames here,
>
> Go on, be bold! You learn a lot by making bold claims and having them
> shot down.

Yes, it's a very effective technique. I just learned another meaning
of the word "trepan" via Savoynet that way. (It's a synonym for its
anagram "entrap", as well as being a surgical operation on the skull.
So now you know, too!)

>> Even Python, which isn't strongly typed,
>> manages polymorphism by allowing the self argument to a sub-class
>> of the method class.
>
> I must admit I don't really understand what this sentence is supposed to
> mean.

As I understand it, there's a little word missing: "... allowing the
self argument to BE a subclass...". That is, in this example:

class A:
    def foo(self):
        return "spam"
class B(A):
    pass

x=B()
print(x.foo())

the method named foo and defined in class A might not get, as its
'self' argument, an instance of class A, but might instead get a
subclass thereof. Thus, polymorphism. Similarly, this C example cheats
a bit, but does work:

struct A
{
    /* ... declare members here */
}
struct B
{
    struct A base;
    /* ... more members */
}

int foo(struct A *self)
{
    /* ... */
}

int main()
{
    struct B obj;
    foo((struct A *)&obj);
}

It depends on the compiler not tinkering with the layout of the
structure at all, which I don't believe is guaranteed but is fairly
safe to assume. (The equivalent C++ code could use real inheritance,
and then it is guaranteed, plus the pointer can be cast implicitly.
But we already know C++ does object oriented code more cleanly.) As
far as foo() is concerned, it's been given a 'struct A', albeit one
with a few extra members after it.

>> True object oriented programming
>> seems to require proper support from
>> the language itself, because the run-time resolution of the "this/self"
>> reference needs specific constructs in the language.
>
> Again, I don't understand what you are trying to say here. Provided that
> the "this/self" reference has a type, what more does the language need to
> provide? The reference itself is enough to identify the instance (since
> it is the instance!) and the instance's type is enough to identify the
> type (since it is the type!).

See above C example - except that true support would include implicit
upcasting, and would thus disallow cross-casting (which the C example
above would have problems with - you could cast any pointer to any
type with the exact same syntax and no compiler warning or error).

ChrisA