On Mon, Mar 28, 2022 at 11:13 AM Chris Angelico <ros...@gmail.com> wrote:
> How do you distinguish conflicts from overrides? > I don't really get it either, but I think one of the points is that you would get an error for any conflict, and then you could choose to override if you wanted to -- rather than accidentally overriding. I've often thought that would be nice -- maybe even as a debug-mode flag or something. In LaTeX, (not a very complex language) there is: \newcommand and \renewcommand so that you have to explicitly override something, and can't do it by accident. That does have some appeal, but probably not as a built-in required feature. class Pizza(Crust, Topping): ... > > and then you could have a conflict like this: > > class StuffedCrust(Crust): > def add_cheese(self): ... > > class ThreeCheeseTopping(Topping): > def add_cheese(self): ... > > which would result in an error when you try to build this pizza: > > class AllTheCheese(StuffedCrust, ThreeCheeseTopping): ... > > But the problem with this example is that it's using Crust and Topping > as superclasses when they're really not. or you put add_cheese in a mixin, which would also work. mixins are great when you have multiple features that you need to mix and match in various ways. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/HAE5BCNDL72EIEFMSWPC7EVWNM4LJKCI/ Code of Conduct: http://python.org/psf/codeofconduct/
