On Sun, 3 Apr 2022 at 18:36, malmiteria <martin.mi...@ensc.fr> wrote: > > Chris Angelico writes: > > And is it still based on the fundamental > > assumption that super() calls THE parent class? > what are you even talking about?
It's been explained before in this thread - your fundamental misconception that there is always a single well defined "parent class". In practice there are cases (which have been noted here) that don't follow that pattern. And if you don't take that into account, any proposal you make will be flawed. > > I don't have the time to read > > that long a post. > Then just read the list of 4-5 features i describe as features of current MRO > + super, at the top of my post, and tell me if you agree with this analysis > or not. Sigh. OK, I'll bite. > 1) a dedicated module for dependency injection and more called alterhitance That's not a feature of the current MRO+super. If you want to write such a module, by all means do so and put it on PyPI. I don't know how popular it will be (given that you don't seem to have the same mental model of inheritance as Python's) but there's nothing stopping you, at least not from just reading this one line description (which you said was OK to do...) > 2) a way to declare inheritance after defining the class (postponed > inheritance) If you want this as a Python feature, you'll need to describe use cases and semantics. But again, you're starting from a model that doesn't match how Python works, so it's hard to see this getting accepted. If the "way" you're suggesting doesn't need a language change, then again go for it and publish it on PyPI. > 3) a solution to the diamond problem You haven't demonstrated that there's a problem to be solved. And even if there is, Python *has* a solution, so what's wrong with the existing solution? > 4) changes to the proxy feature of super (that i already mentionned earlier > in this thread) What's wrong with how it is now? You can't argue for change unless you understand the current model, and so far you've demonstrated that you don't, and you're not willing to accept the explanations that have been offered. > 5) changes to the method resolution algorithm (that i already mentionned > earlier in this thread) Same as for (4), what's wrong with it now? Overall, you stand very little chance of getting anywhere with this as you seem to be unwilling to make the attempt to understand people's objections. And you just keep posting huge walls of text that no-one is going to read, because they make no sense to anyone who is familiar with, and comfortable with, Python's existing model. So you're never going to persuade anyone who doesn't already agree with you... Paul PS Please don't respond to this with another wall of text. I won't read it. If you can't summarise the basic idea behind your proposal in a single paragraph, it's probably too complicated, or too incomplete, to succeed anyway. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/I7GNHKSVMRJOXSJSPYK3Q4VZIFWYWBPW/ Code of Conduct: http://python.org/psf/codeofconduct/
