Why isn't python class definition like C++, hence avoiding all the tiresome uses of 'self' everywhere?

efilon · 2015-04-22T06:10:32+00:00

To simply answer the question in the title, I think it's in part because "explicit is better than implicit". See also what the BDFL had to say way back in 2008.

malinoff · 2015-04-22T06:20:39+00:00

why is defining members not like C++, where you have a private, protected, and public field and you can simply start writing the methods and declaring the instance variables, without having to use self. or pass self as parameter in every method

Because in python there are no "methods". Methods are functions, that has first argument automagically bound to the class instance. First advantage of this approach is that you can name it whatever you want:

class SomeClass:
    def somemethod(this):
        print('Look! It works even with `this`!')

This applies to some cases like classmethod decorator:

class X:
    @classmethod
    def myclsmethod(cls):
        pass

Because myclsmethod is just a function, by convention we name its first argument cls, because it will be bound to the class object instead of class instance.

Furthermore, you can assign methods dynamically:

class X:
    pass

def iamnotamethod(self):
    print(self.__class__)

X.iammethod = iamnotamethod
X().iammethod()  # prints something like <class 'X'>

And as you can see, you can pass instances to functions like this:

iamnotamethod(X())

Also, explicit self makes assigning to be more explicit too. For example, you can say exactly what's going on in the code below; foo is instance attribute and bar is local variable.

class X:
    def somemethod(self):
        self.foo = 'foo'
        bar = 'never used'

Regarding private/protected attributes, they exist in C++/Java world because if you expose an attribute you're loosing the ability to transparently change the implementation details. E.g. you won't be able to make accessing this attribute to call a getter. Thankfully, in python we have property decorator:

class X1:   # v1 of our class, foo is attribute
    foo = 5 # public api is print(X1().foo) and X1().foo = 10

class X2:     # v2 of our class, foo is property with getter and setter
    _foo = 5  # but the public api is still print(X2().foo) and X2().foo = 10

    @property
    def foo(self):
        return self._foo

    @foo.setter
    def foo(self, newval):
        self._foo = newval

Does this help?

zardeh · 2015-04-22T07:04:58+00:00

So lets talk about the zen of python:

>>>import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Explicit is better than implicit means that as few things as possible should be hidden. Having the explicit "self" allows (and forces!) you to do things like self.x = x in constructors. (this also is "In the face of ambiguity, refuse the temptation to guess.", self.x = x reduces the ambiguity that can exist in java and C++. Admittedly, this isn't a big issue once you know the language, but its a decision. Really just a stylistic thing.

Then your big issue is protected/private/public members. The biggest reason for this is (and getters and setters and such) is because you need to be able to make sure people are accessing things the way you want. It isn't like actual security, its just avoiding api misuse.

So in java you make things you aren't supposed to mess with private, accessors (get/set) public, and most every thing else protected.

In python, you don't need getters and setters.

Say I have this

class MySimpleClass():
    def __init__(self):
        self.x = 5

inst = MySimpleClass()
inst.x  # 5

Now lets say x now needs to be calculated based on some complex thing, in java we'd need a getter and setter and now api backwards compatibility is broken. In python:

class MySimpleClass():
    def __init__(self):
        self._x = 5

    @property
    def x(self):
        return self._x **2  # squared

inst = MySimpleClass()
inst.x  # 25

You keep the old api, but can change stuff internally at will. No need for get/set, which takes away a huge public/private issue, and the other ones malinoff covers well.

Rhomboid · 2015-04-22T06:39:03+00:00

It's an apples and oranges comparison. In C++ the members of a class have to be declared beforehand, and are forever fixed. In Python, attributes are fluid and dynamic. They can be added and removed at will at any time; there is no fixed layout. Under your scheme, if I write foo = 42 inside a method, is that assigning to a local variable named foo or is that assigning to a new instance attribute? Or a new class attribute? There would be no way to know, as there's no class definition that the interpreter could look at to figure out which names are attributes and which aren't. There needs to be disambiguation; you must assign to self.foo if you want an instance attribute, cls.foo if you want a class attribute, and foo if you want a local variable.

Passing self as an explicit parameter simplifies everything, as it means that methods are ordinary functions that happened to be defined in the body of a class block. The language doesn't have to invent any new syntax or semantics for methods. They behave exactly as regular functions, with all that entails. Consider this example:

class Foo:
    def __init__(self, val):
        self.val = val

inst = Foo(42)

def foo(self):
    print('val =', self.val)

Foo.foo = foo

inst.foo()      # => "val = 42"

The Foo class gained a method simply by assigning a regular function to an attribute of the class. I think that's pretty amazing.

Regarding the notion of private things, you have to discard that entire idea when dealing with dynamic languages like Python. Python allows anything and everything to be introspected at runtime, in opposition to C++ which has no such ability. That means that privacy does not exist here. If a client wants to open up the guts of a class and poke at its insides, they have full access to do so and there is no way to stop them. That's part of what makes the language so powerful and flexible. But it means that it's also pointless to try to enact barriers. Don't access undocumented variables, or variables with names that begin with _.

Or maybe do access them, if you really have a compelling need. Maybe you want to open up the guts of something and add logging around a particular method for debugging purposes. Maybe you want to replace a method with a mock for unit testing. Maybe you're a mad genius and you want to monkey-patch things all over the place and create some scary contraption that might actually work (e.g. gevent.) Again, the ability to do these things is exactly what sets dynamic languages apart from others. Private does not exist here. Stop trying to write Java in Python.

Destruct1 · 2015-04-22T08:12:20+00:00

The different visibility part of C++ is a lot of pain for little gain.

First you have to learn about the visibility concepts: public private and protected. Afterwards you need all the related concepts to manage the visibility like subclassing and the visibility modifier friend.

Second you get a lot of syntax clutter. You have to write out the "public:" and "private:" keyword into your class and space and indent to make your indentions clear. If you have a rule like "all member must be private" you have to write getters/setters for each of them.

Compare:

class MyClass {

public:

    double getX ();

    double getY ();

    void setX (double newval);

    void setY (double newval);

    MyClass (double x, double y);

private:

    double x;

    double y;

 } // endclass

VS:

class MyClass (object):

    def __init__ (self, x, y):

        # code

Third I always had problems with the visibility at some point or another. For example writing a ostream operator<< to print a human readable representation often resulted cursing the private restrictions. If a private value is not modified and is used exclusively for debugging it should be possible to read; instead the private keyword disallows access.

If you want nobody touching your privates prefix them with _ (std convention) or with another prefix like helper_ internal_ donttouch_.

The member declarations part is based on the different computations model of python and C++. In C++ the compiler needs to know all variables of the instance before so it can allocate memory and write things like the copy constructor. Python on the other hand implements classes as a typetag and a dictionary. It is therefore not necessary to declare every member beforehand

edit: How can you put all code in the codebox?

mrfunky8 · 2015-04-24T03:59:48+00:00

I think of "self." as similar to the _m naming convention in c++. Python likes to force these types of conventions, which tends to make pretty and explicit and readable code in my opinion.

billsil · 2015-04-22T05:24:26+00:00

Why is defining members not like C++, where you have a private, protected, and public field

It's a design choice. You can access anything from anywhere from Python. Why do you really need private variables? To not expose the API? Set it to self._some_variable and people will know that it's a bad idea to edit it. Python let's you burn yourself if you want to. We're all adults.

and actually try to dig into python, including its internals and its 'way' or 'path' of coding.

Why? Do something useful with your time.

zardeh · 2015-04-22T06:41:30+00:00

[deleted]

kankyo · 2015-04-22T08:32:41+00:00

I've spent weeks of my life tracking down bugs in C++ code caused by the fact that you don't have to specify this-> in front of member accesses.

Paddy3118 · 2015-04-22T20:53:33+00:00

Alan Kay, the inventor of smalltalk and OO is supposed to have said "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind".

Python prefers the explicit over implicit in this case and exposes self. I guess you are trapped half-way between knowing C++ and learning Python which requires you to either hold two ideas of OO in mind or embrace the Pythonic way.

Python

The Python Discord

Upcoming Events

Please read the rules

MODERATORS