"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4