why is "self" used in OO-Python?

[bruno.desthuilliers at gmail.com]

On 12 juil, 18:32, 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.
>
> 1. Why do I have to pass self into every method in a class?

You mean "declare self as the first argument", I assume ?

This has been explained many times here. Anyway: the point is that
what you define is not a method, but a function. This function needs
to have a way to get at the instance on which it's called, and the
simplest way to do so is to use the common way: passing it as an
argument. This avoids having to have two different constructs -
functions and methods - when one is enough.

> Since I am
> always doing why cant this be automated or abstracted away?

This could, probably, but you'd had complexity, break uniformity and
loose some interesting features of the language.

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

I don't know if it's "one of the main purposes", but you're missing
the point: you have to use explicit getters and setters in Java
because Java doesn't have any support for computed attributes. In
Python, the object.attribute syntax doesn't mean you are directly
accessing an instance attribute. First because lookup rules are more
complex than that (not only the instance, but also it's class and it's
class parents are looked up), then because there are several ways to
hook into these lookup rules. Given that you can decouple the
interface (looks like an access attribute) from the implementation
(anything from an instance attribute to a method call in a distantly
related class, possibly including a network connection and database
access), you just don't need explicit getters and setters when
directly accessing an instance attribute is enough (and that's more
than often the case).

>  Doesn't messing with internal object-
> representations break this?

It does, indeed, but it's sometimes necessary (as a matter of fact,
there are ways to get at private attributes even in Java). Anyway,
this is unrelated to your above question about getters and setters.

> 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.

Unless you need to do something else than accessing an instance
attribute, explicit getters and setters in Python are a pure waste of
time for you, anyone using your code, and even the computer.

> Only looking at the documentation of a Python-class, will internal
> representations be provided?

For which definition of "internal representation" ?

> If I have a class:
>
> class Stack(object):
>     def __init__(self, *items):
>         self.stack = list(items)
>
>     def append(self, item):
>         self.stack.append(item)

# OT : canonically, it's stac.push(item), not 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.

Because you may want to change the implementation, as usual. But you
shouldn't expose stack as part of your API. The convention in Python
is to name implementation stuff with a leading underscore. This a
*very* strong convention saying "don't mess with this unless you know
exactly what you're doing and are willing and able to take full
responsability if you break anything or if your code breaks when I'll
change my class implementation". So just rename 'stack' to '_stack',
and anyone using your class will ignore it unless they have a pretty
good reason to mess with it and are ok to suffer the potential
consequences.

> That way you could do away with OO completely.

You could, but what would be the point ? Why would I mess with
implementation when I get what I need using the API ?

> So why let people
> access the main attribute but not let them manipulate it?

You just can't stop them from manipulating it if they really want, you
know. Don't worry, whatever the language, if someone want to mess with
implementation, he will find a way.

> Makes more sense to draw the line to not access any attributes at all
> no?

No. Most programmers are of at least median intelligence, and won't
even have a look at your implementation as long as they can - because
they don't want to have to worry about implementation. As long as you
clearly marked something as being "implementation, don't touch", and
provided a sound API, then you've done your job.

I know this can sound disturbing when coming from the ultra-dogmatic
chains-and-bondage world of Java, but from experience (from dozens of
years of thousands of programmers), Python's pragmatic approach
JustWorks(tm).