PEP 318

[Jacek Generowicz]

Nicolas Fleury <nid_oizo at yahoo.com_removethe_> writes:

> I've given some Python courses, and the first reaction when showing
> a class with some methods is something like "so I guess when the
> first parameter is not named 'self' it makes a class method?".

Just as a point of information:

I teach Python courses ... hands-on interactive style ... class size =
12 ... I've given 8 of these so far ... I have _never_ had this
reaction. (80% of the students have previous C++ and/or Java
experience, and usually someone asks "How do I do class/static
methods?".)

Maybe the reason nobody believes this is because, fairly early on in
the treatment of classes, I point out that there is nothing special
about the name "self", but I usually ask the students what they make
of it, before offering any of my own comments.

> If easing the creation of class methods is so important, I would
> prefer a more radical approach with a end result that would be more
> intuitive to newcomers:

While I agree that there is a lot to be said for Python being guided
by the principle of least surprise, I would argue against letting
Python be shaped by the expectations of people whose expectations have
been moulded by Java and C++, as those expectations are typically
fundamentally flawed, and certainly inappropriate to Python. (For
example, most (Java and C++ people, and hence generally most) people
expect there to be access control, and hundreds of getters and setters
all over the place. We do _not_ want this in Python. Etc., etc..

> - Give a warning for all methods with first parameter not named "self"
> in next versions of Python.

That would be acceptable ...

> - In a future major version of Python, 3 or 4, self becomes a keyword
> and a first parameter named otherwise implies a class method (I
> understand it could mean a lot of changes in code not using self).

... that would (IMHO) not.