Greg Ewing writes: > 1. You hate the existing MRO and super() mechanism with a passion > and want to rip it out. I don't hate it, I believe it makes for the most misunderstood python feature for a reason, and i'm trying to adress it.
> 2. People have objected that this would remove useful funcionality. To which i've replied accordingly. If you feel I missed any use case of today's MRO + super, and haven't provided at least equivalent APIs for them, please let me know what you are thinking about. So far, i've been objected : - Dependency injection (in the inheritance tree), which can be covered today by updates to __bases__ anyways, but i propose to produce a dedicated module. - The diamond problem, which behavior would change with my proposal, I've introduced the inheritance strategy module, allowing anyone to choose which strategy they want, and defaulting to today's behavior, which makes for a transparent transition. - Mixins (actually, i don't think anyone opposed that use case to me, but it's still one to deal with), which i cover with what i called postponed inheritance in my lenghty post, but i now kinda wanna refer to it as adoption. It feels like a better name. > 3. You address 2 by proposing a bunch of new mechanisms to replace > the lost functionality. 3, not 2, and again, if you see any more use case not covered yet, please let me know. > But you haven't adequately justified step 1 yet. Again, i've addressed multiple scenarios in which today's super and MRO make for a confusing experience, and the API i propose are more straightforward, and provide a smoother learning curve. _______________________________________________ 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/K2IP43GWBZKOINGK5RQB4FDOZMQK5ONY/ Code of Conduct: http://python.org/psf/codeofconduct/
