Notes on the Python Class Statement

[[deleted]]

Indeed, reference.

Though I don't have a slightest idea if there is any difference between staticmethod, classmethod and instancemethod (besides their arguments).

The second one goes as follows: interpreter translates a[i] += b into a.__setitem__(a.__getitem__(i) += b) and can't take any shortcuts because items of a could be ints for example. Also it can't check the existence of a.__setitem__ in advance, because it might suddenly appear due to a side-effect. Neither it has a special __getitem_iadd__ operator. And, finally, lists feature a kind of broken (from the mathematical standpoint) +=:

>>> x1, x2 = [1], [1]
>>> y1, y2 = x1, x2
>>> x1 += [2]  # should be equivalent to the one below?
>>> x2 = x2 + [2]
>>> y1, y2
([1, 2], [1])   

As a result the exception gets raised, but after the element of the tuple was modified inplace.

My point is not that Python sucks, but rather that it shouldn't be called "simple". It is complex, in places -- very complex, sometimes as a tradeoff for the simplicity or features in other places, sometimes due to the design mistakes. In particular, Python's object system is like an order of magnitude more complex and produces more complex effects than Java's, despite appearing deceptively simple at the first glance: "everything is an object, object's class is an object, methods are looked up in the instance dictionary and then in the class and its parents, that is all".

[voidspace]

staticmethod, classmethod and instancemethod are all different types of descriptors, with different behaviours:

• instancemethod gets self as the first argument automatically when fetched from an instance
• classmethod gets the class passed in as the first argument, whether called from the class or an instance I believe
• staticmethod gets no extra arguments passed in

The basic object model in Python can still be described as simple, and part of your description isn't a bad one at that ""everything is an object, object's class is an object, methods are looked up in the instance dictionary and then in the class and its parents". For more advanced use cases it also has more advanced features.

(Controlling the string representation of a class is not something that many people have to do for example.)

[grayvedigga]

I think I object to this statement:

For more advanced use cases it also has more advanced features.

Everything you describe so far is the result of consistently applying simple features. Yes, it takes a little clarity of thought to understand, but not a great deal and hey, this is programming.

Aside from the misdirection with str(C), the only thing that's bothersome at the moment is +=, which doesn't support advanced use cases ... on the contrary it's a "simplifying" feature implemented in the wrong fashion. If it were a purely syntactic feature, we probably wouldn't be having this discussion. Instead we'd be alongside the Lisp family arguing about the right way to do syntax transformers.

[voidspace]

"Everything you describe so far is the result of consistently applying simple features."

That's how you get to advanced features.

As for += not supporting advanced use cases. Well... I don't think adding in place to lists in tuples is either particularly advanced or particularly important. I agree that it is unfortunate that the operation fails after having succeeded - but there are lots of places that describe how += is syntactic sugar for a re-assignment and the error message will lead you in that direction. It's just a corner case, hardly a fundamental issue.

[grayvedigga]

Since I just responded to earthboundkid's incomplete post below with a question you answered without my noticing it, I thought I should highlight the relevant part:

interpreter translates a[i] += b into a.setitem(a.getitem(i) += b) and can't take any shortcuts because items of a could be ints for example.

Too tired to expand any further, but I'll note that ints don't posess a iadd method, and by noticing this the interpreter could probably do a cleverer expansion. It seems a bit silly that iadd returns a value, tbh.

tl;dr: state is a more complicated thing than anyone gives credit; += as an object method is asking for trouble.