Why the 'self' argument?

Harri Pesonen fuerte at sci.fi
Mon Sep 8 21:39:20 CEST 2003


John Roth wrote:

> "Harri Pesonen" <fuerte at sci.fi> wrote in message
> news:TRr6b.4056$ZB4.1410 at reader1.news.jippii.net...
> 
>>Grant Edwards wrote:
>>
>>>In article <Ucp6b.3992$ZB4.3874 at reader1.news.jippii.net>, Harri Pesonen
> 
>>>>I agree, it's not logical. I'm learning Python at the moment, and like
>>>>it very much. This "self" thing seems to be the only odd feature,
>>>
>>>It seemed quite natural to me, but perhaps that's because I'd
>>>used other languages that worked the same way.  Coming from
>>>Modula-3 and Smalltalk, the way classes worked in Python seemed
>>>quite intuitive.
>>>
>>>OTOH, C++ seems like a real non-intuitive mess to me.
>>>
>>>>it feels like the whole class feature was added later.
>>>
>>>Why?
>>
>>Because everything else in Python seems to be very compact, there are no
>>variable type declarations, or variable declarations, or anything else
>>unnecessary that can be omitted. I would like to have self omitted, it
>>would make the class syntax more beautiful and compact. On the other
>>hand, I would like to have real private methods.
>>
>>Also I think that the class members should be explicitly declared. In
>>general, it would be nice to have an option (like Option Explicit in
>>Visual Basic) so that you can't assign to variables that have not been
>>declared. It would probably make Python less error prone.
> 
> I believe that is what __slots__ is for. That's run time rather than
> compile time, but at least it gives you the error on the statement
> that attempts to do an invalid assignment.

Thanks guys, I hadn't heard of __slots__ before. Perhaps I am reading a 
too old book. Of course, a compile time check would be better...

>>Also if
>>variable declarations could have the type, again some errors could be
>>detected at compile time.
> 
> It's quite possible to add run time type checking to Python, at a
> significant cost in performance. See the descriptors material.

I think that Python already has run time type checking. It does not 
allow "a" + 1, for example.

> There's been quite a bit of work on a compile time type checking
> system over the years, but it has never resulted in a proposal that could
> be agreed on.

It would be quite simple to have "option explicit" like in Visual Basic, 
I believe. Like the following:

option explicit
var a = "asdf"
b = 1 # error at compile time
a = 123
(var b, var c, var d) = (1, 2, 3)
e = "asdf" # error at compile time

Always have "var" keyword before first assignment. Just a proposal. You 
don't need __slots__ (which sounds like a hack):

class A(object):
	var a, var b, var c
	# instead of __slots__ = ['a', 'b', 'c']

foo = A()
foo.a = 1
foo.b = 2
foo.c = 3
foo.d = 4 # error at compile time

> My own personal opinion is that I like the type check system in
> the ML family of languages: it stays out of your way unless you need it.
> How that would fit in Python is another question, though.
> At this time, it looks like an issue for Python 3.0, which seems to
> keep receeding into the distance.

I think that the type checking is not so important, but you could have 
it as well:

var a as str = "asdf"
var b as int = 123
var c as float = 123.4
a = 123 # error at compile time
# also at run time if not detected earlier
var d = "asdf"
d = 123 # ok, because no type was defined

Harri





More information about the Python-list mailing list