[Python-Dev] Breaking calls to object.__init__/__new__

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20703212037g3e03df1fq433a988257d10112 at mail.gmail.com...
| There are different philosophies about the correct style for
| cooperative super calls.
|
| The submitter of the bug report likes to remove "consumed" arguments
| and pass the others on, having something at the root that complains
| about any unused arguments. It has the problem that you mention: if
| multiple classes might be interested in the *same* argument they won't
| see it. The other style is to pass *all* arguments down, and let
| everyone cherry-pick them. The last call then just throws them away.
| This has the problem that misspelled arguments are silently ignored
| rather than being diagnosed at the point where you can do something
| about it.
|
| I don't know what the "best practice" is (like Greg Ewing, I don't use
| either style myself) but I've got a feeling that it must be easier to
| solve the former problem than the latter (also I don't know that the
| former actually occurs in practice). When using more traditional
| styles, or single inheritance, it certainly makes more sense to reject
| excess arguments than to ignore them; the original code was clearly
| intending to do this, but due to the minimalist coding, it didn't
| catch enough.

It seems to me that to get the exact behavior one wants at the apex of a 
diamond structure, one should subclass object and override .__init__  with 
a function that does not call object.__init__  and use that subclass as the 
apex instead of object itself.  Wouldn't this mask the behavior of 
object.__init__ and whatever changes decided on?

(But having said that, I have no opiniou on what the default should be for 
those who don't do this.)

Terry Jan Reedy