why is "self" used in OO-Python?

[castironpi]

On Jul 12, 1:01 pm, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
> ssecorp <circularf... at gmail.com> wrote:
> > 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.
>
> When you define a method in Java there is an implicit 'this' passed to the
> method. Python cannot tell when you define a function whether the function
> is going to be used as a function, an instance method, a class method, a
> static method or something else (or all of the above). Consider this:
>
> The dynamic nature of Python means you can lift a method out of a class and
> re-use it in a different context or inject a function into a class as a
> method. There are two ways to handle this sort of code: javascript has an
> implied 'this' for everything whether a function or what passes for a
> method, Python makes it explicit.
>
> > 2. self.item instead of getters and setters. I thought one of the main
> > purposes of OO was encapsulation. Doesn't messing with internal object-
> > representations break this?
>
> That is correct. Some languages (e.g. Java) don't allow you to encapsulate
> attributes so you have to write getter and setter methods. If you expose an
> attribute in Java then you cannot later insert some code into the lookup or
> override the set without getting all users of your code to change the way
> they access the value. This is bad.
>
> Other languages (e.g. Python, C#) allow you to intercept the attribute
> lookup so you can change a plain attribute into a property without
> requiring the users of your class alter their source code. With C# I
> think they would still need to recompile their code so it may be more
> appropriate to avoid using public attributes if you are producing a class
> library for widespread reuse, but with Python there is no difference to the
> user of your class whether they are accessing an attribute or a property.
>
> Sadly a lot of Java programmers mistake the limitations of their language
> for rules of OO programming, and worse this has spread from Java into other
> languages where these restrictions no longer need apply.
>
> Your Stack class is a bad example: the stack attribute is purely internal
> so you wouldn't want to expose it as part of the public interface. Consider
> instead something like:
>
> class AddressBookEntry(object):
>     def __init__(self, name, phone):
>         self.name = name
>         self.phone = phone
>
>     @property
>     def phone(self):
>         return self._phone
>
>     @property.setter
>     def phone(self, number)
>         validatephonenumber(number) # may throw an exception
>           self._phone = number
>
> If later you want to add some processing to the name attribute it is easy,
> but putting in dummy property getter/setter methods before you need them
> would be pointless.

Part of the value of accessor methods appears when you're changing
class definitions, or changing classes, after you've already started
to use them-- the same interface with a different implementation.

In the AddressBookEntry example, if you changed a pickled dictionary
to a shelf, you could reimplement the class and reprocess stored data
files, all without changing the code that uses the class-- especially
if there's a lot of it, or you don't know where it all is.

Nothing stops you from using accessor methods to offer encapsulation,
and permit back-end changes later.  But, nothing in Java stops you
from declaring class members public.

Depending on your development process, data hiding may enforce
distribution of labor a little better, resulting in errors in Java
where Python relies only on discipline.  If you're checking for value
validation, you can write a custom setter, regardless of language.

Python doesn't break encapsulation; you do.

In the Stack example, you have more options than you've mentioned.
Can you inherit from list directly?  Can you delegate using
reflection?  Are you studying this example specifically, or the class
model generally?  If you're choosing a language, be careful that
stricter enforcement doesn't cause harder-to-find bugs.

Useful link: Section 9.4 in the docs: http://docs.python.org/tut/node11.html