What is the semantics meaning of 'object'?

[Mark Janssen]

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

Here's how it *should* be made:  the most superest, most badassed
object should take care of its children.  New instances should
automatically call up the super chain (and not leave it up to the
subclasses), so that the parent classes can take care of the chil'en.
 When something goes wrong the parent class has to look in and see
what's wrong.

In other words, this habit of specializing a Class to make up for the
weaknesses of its parent are THE WRONG WAY.   Instead, let the
specialization start at the machine types (where it doesn't get more
specialized), and work UPWARDS.

Let the standard library make the grouping (or collection types) to
point to the standard way of data structuring, and then everything
else becomes little mini-apps making a DataEcosystem.

--mark