why is "self" used in OO-Python?

[Carl Banks]

On Jul 12, 12:32 pm, ssecorp <circularf... at gmail.com> wrote:
> I first learned about OO from Java.
>
> I much prefer to program in Python though.
>
> However I am consufed about 2 things.

Short answer is, "Java isn't the only way OOP."

Longer answers follow.


> 1. Why do I have to pass self into every method in a class? Since I am
> always doing why cant this be automated or abstracted away?
> Are the instances where I won't pass self?
> I imagine there is some tradeoff involved otherwise it would have been
> done away with.

This is pretty simple: it was judged to be significantly more readable
if you mark class variables explicitly.  That is, when you see
something like "self.var" you instantly know it's an attribute of the
object and not a local or global variable.

That you sometimes see Java and (more often) C++ guidelines that
recommend always using "this" for accessing class members shows that
it's somewhat helpful to keep them visually distinct from other
variables.

I think it's a minor point, really, that people make a pretty big deal
over.


> 2. self.item instead of getters and setters. I thought one of the main
> purposes of OO was encapsulation.

Just as an aside: the usage of getters and setters probably does more
to thwart encapsulation than to protect it, in practice.

You see, it doesn't matter whether you access a member directly, or
through getters and setters: you're still accessing the member.
Getters and setters don't encapsulate your data one bit.  All they do
is to add a bunch of mostly unnecessary boilerplate.

OTOH, many people add getters and setters recklessly, based on the
above misconception.  Not only are they exposing internal details by
doing this, they're also giving the user a blessing to use them.

The practical advantage getters and setters have in Java is that, if
your class implementation changes and you no longer wish for something
that was once a single variable to be that way anymore, you can change
your underlying implementation without changing the interface.  That
advantage does not exist in Python, however, since in Python one can
do the same thing with properties.


> Doesn't messing with internal object-
> representations break this?
> I see how the getters and setters could be just visual clutter and you
> have to add them to every class so it is annoying a bit in the same
> way as self described above.
> However I feel like I want getters and setters when I write classes,
> not sure of the advantages/disadvantages though.
> Only looking at the documentation of a Python-class, will internal
> representations be provided?
>
> If I have a class:
>
> class Stack(object):
>     def __init__(self, *items):
>         self.stack = list(items)
>
>     def append(self, item):
>         self.stack.append(item)
>
>     def pop(self):
>         return self.stack.pop()
>
> I can get to see the stack with var.stack but then why even implement
> append when I could do self.stack.append(x) etc.
> That way you could do away with OO completely. So why let people
> access the main attribute but not let them manipulate it?
> Makes more sense to draw the line to not access any attributes at all
> no?

Much of what you're arguing is only true if you accept it as a given
that data hiding is important.  The designers of Python don't really
think it is, and that's why they don't have it.


Carl Banks