[Python-Dev] Breaking calls to object.init/new (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Mar 22 05:19:12 CET 2007

"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

More information about the Python-Dev mailing list