Python was designed (was Re: Multi-threading in Python vs Java)
Chris Angelico
rosuav at gmail.com
Sat Oct 19 06:49:04 EDT 2013
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
More information about the Python-list
mailing list