What is the semantics meaning of 'object'?

[Chris Angelico]

On Wed, Jun 26, 2013 at 3:44 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sun, Jun 23, 2013 at 1:33 PM, Antoon Pardon
> <antoon.pardon at rece.vub.ac.be> wrote:
>> Op 23-06-13 18:35, Steven D'Aprano schreef:
>>> Please don't. This is false economy. The time you save will be trivial,
>>> the overhead of inheritance is not going to be the bottleneck in your
>>> code, and by ignoring super, you only accomplish one thing:
>>>
>>> - if you use your class in multiple inheritance, it will be buggy.
>>
>>
>> Which is why I don't understand that the python standard library still
>> contains that kind of code. At least it did in 3.2 and I saw nothing
>> in the 3.3 release notes that would make me suspect this has changed.
>
> This bothers me as well.  If you look at Raymond Hettinger's "super()
> considered super" article, he includes the (correct) advice that
> super() needs to be used at every level of the call chain.  At the end
> of the article, he offers this example to show how "easy" multiple
> inheritance can be:
>
> from collections import Counter, OrderedDict
>
> class OrderedCounter(Counter, OrderedDict):
>      'Counter that remembers the order elements are first seen'
>      def __repr__(self):
>          return '%s(%r)' % (self.__class__.__name__,
>                             OrderedDict(self))
>      def __reduce__(self):
>          return self.__class__, (OrderedDict(self),)
>
> oc = OrderedCounter('abracadabra')
>
> Which is pretty cool in its simplicity, but here's the rub (which I
> have previously noted on this list): OrderedDict doesn't use super.
> Counter does, but not cooperatively; it just calls super().__init__()
> with no arguments.  So the fact that this example works at all is
> basically luck.

The main problem is getting to the top/end of the call chain. Classic
example is with __init__, but the same problem can also happen with
other calls. Just a crazy theory, but would it be possible to
construct a black-holing object that, for any given method name,
returns a dummy function that ignores its args? (Other forms of
attribute lookup aren't going to be a problem, I think, so this can be
just methods/functions.) Then you just subclass from that all the
time, instead of from object itself, and you should be able to safely
call super's methods with whatever kwargs you haven't yourself
processed. Would that work?

Caveat: I have not done much with MI in Python, so my idea may be
complete balderdash.

ChrisA