Reasoning behind 'self' parameter in classes?

[Patrick Mullen]

On Wed, Jul 30, 2008 at 12:27 PM, Robert Dailey <rcdailey at gmail.com> wrote:

>
> Given the code samples above, is there any technical reason why this cannot
> be done? Thanks for the input guys, and thanks more over for keeping this
> easy-going.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>


Well, the linked thread gives many reasons, but as mentioned it is a
flamewar thread.  Philosophically python is not an "object oriented"
language per say, it has an object system, a not bolted on one I might add,
but it doesn't force developers to use that methodology.  You can be
functional or procedural if you'd rather.  Following this philosophy, when
methods were designed, they were merely functions that got passed an
instance as the first argument.  The parser followed this design choice.  As
far as I understand it, the underlying method object is not different from a
function argument, thus it cannot have any magic arguments built in.  The
only magic involved is the fact that the object, when calling a method, will
pass its instance as the first argument.

I don't believe there is any chance of this changing in python 3, python 4
is anyone's guess...

This does allow some good things that come for free, like adding methods
later, or changing functions into methods or methods into functions.  If you
start out developing a class, but feel a class is too bulky, you can delete
the "class" line, dedent the methods, and have a set of functions instead
for free.  Or, if you have functions that are set up to take instances as
their first argument already, you can bundle them up into a class very
easily.

If by "hack" you mean using features already available in the language to
accomplish things, that kind of is what it is, and that's kind of what
python is about.  New syntax for a new feature is uncommon, but it happens.
New syntax that breaks old code is very uncommon, and is only now coming out
in python 3.  And the biggest change in python 3 is to eliminate added
syntax, such as print being a statement, and make the code reuse more python
features rather than have every feature exist as an island.  Print being a
function, for instance, lets you use the same syntax for it that you use for
other functions, making everything clearer and more unified.  A common thing
programmers might do when upgrading their code is to turn print statements
into better logging functions - if print was a function in the first place
this would be an easier task.

Eliminating self doesn't accomplish much, and changes of this nature just
don't get done without a good reason.  It takes away something that might be
annoying, but doesn't add anything.  The benefits of changing have to be
significant for a code change to break the existing syntax.  Many people are
upset even about some of the changes in python 3, that the benefits don't
outweight the cost of change, and most of those changes are less damaging
than playing around with the self businss would be :)

So no, self not a mysterious thing that we should never question.  Self is
an understood thing that has been questioned very often (weekly, monthly)
for many many years - there are not enough good reasons to bother with
changing it, and there enough good reasons for it that it's best to keep it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080730/df455aa0/attachment-0001.html>