On Sat, 16 Apr 2022 at 14:25, Steven D'Aprano <st...@pearwood.info> wrote: > > On Sat, Apr 16, 2022 at 11:07:00AM +1000, Chris Angelico wrote: > > > On Sat, 16 Apr 2022 at 11:00, Steven D'Aprano <st...@pearwood.info> wrote: > > > > and therefore > > > > would become the only thing that offers "full MI", displacing other > > > > languages. It's a meaningless concept, unless there is some form of > > > > absolute completeness that can be attained > > > > > > Well duh Chris, sometimes I wonder if you read my posts before jumping > > > in to disagree with me, that is *exactly* what I am arguing. > > > > You placed a LOT of caveats on it. I don't count that as "absolute > > completeness". It is the most complete that YOU, right now, think > > could ever be possible. > > Which conditions would you drop? There's not that many, really. Five. > Six if you include the "no cycles" requirement for the DAG, which I > think is so obviously necessary that it is barely worth mentioning.
This is *exactly* the "no true Scotsman" fallacy: you have already excluded from consideration anything that drops a condition you didn't already drop. On the assumption that your five conditions are essential, there's no way that you can drop any of the five conditions and still have it count, therefore the five conditions are essential. Your logic is circular. It is highly arrogant to assume that nobody will ever find a way to implement MI while dropping one of your conditions. They're not fundamental to the definition, they're fundamental to *the way Python does things*. > The most subjective is the requirement for automatic conflict > resolution. It is a legitimate design choice to give up automatic > conflict resolution (that's what C++ and Eiffel do) but that would be a > breaking change for Python. Yes. A breaking change FOR PYTHON. > So come on Chris, back up your disagreement with something objective, > not just wishy-washy "anything might happen in the future!" nonsense. Yet you're willing to argue that other languages don't do "full MI" because they do things that would be a breaking change for Python? > No, not everything is possible. We're never going to discover a new odd > number between 3 and 5, or that 7 isn't really prime, or that cats are > actually a type of plant, or that Australia doesn't exist. You would be very surprised what people HAVE discovered. For instance, it's very common to define the distance between two numbers by subtracting one from the other, but that isn't the only internally-consistent definition of distance that could be used. The only things that we can completely rule out are those which are true by definition, or can be proven mathematically or logically. A new odd number between 3 and 5 is provably impossible. 7 is truly prime, by the definition of primes, and any extension to that definition (eg complex primes or Gaussian integers) must maintain that. Discovering that Australia doesn't exist would be world news, but might indicate that we'd finally angered some nuclear country enough to get ourselves completely blown off the map. (Yeah, I know countries like Russia and the US don't have enough nukes to do that, but we have no idea what sort of arsenal Ghandi is hiding, just waiting for his stats to become negative...) > So be concrete: which of my preconditions do you want to challenge? > > - The inheritance model automatically resolves conflicts. > > As I said, it is a legitimate design choice to give that up, but it > would be a breaking change for Python so we can rule it out. > > In any case, languages without automatic conflict resolution do less > than languages with them. (That might be a good thing.) This is the essence of the "no true Scotsman" fallacy: you assume that it's not true MI without automatic conflict resolution. > - The MRO is entirely dependendent on the shape of the inheritance > graph, and not on incidental properties like the name of classes. > > Let's hear your justification for why breaking that condition is good. > > "I changed my class name from Spam to Eggs, and suddenly the inheritance > relationships between my classes changed." > > "That's not a bug, that's a feature!!!" Is it not true MI if the relationships change? Is that what you're saying? What is "full MI"? > - the inheritance model is consistent, monotonic and preserves local > precedence order (C3 linearization). > > Which of those three will you give up, and why is that a good thing? > > "In my class Spam, superclass A takes precedence over B, but when I > subclass Spam, the precedence swaps and B comes before A." > > "That's not a bug, that's a feature!!!" You keep asserting that, because something OBVIOUSLY would be a bad thing for Python, it must not be "true multiple inheritance". That's why you're being called out for the NTS fallacy. Your entire definition of "full MI" is "Python 2.3+". > > > If you exclude models of MI which are logically incoherent and > > > inconsistent, (such as Python's prior to version 2.3), then Python's > > > model of MI is objectively as complete as you can get. > > > > If you assume that what we know in 2022 is the most we will ever know, > > then yes, you would be correct. Do you really think that nobody will > > ever learn anything new about ways of doing MI? > > Yes. Its a DAG of superclass/subclass relationships. There is only one > way to draw that graph that is coherent. Can you mathematically prove that? What if there is some other way to linearize that is *also* consistent with itself, but different from C3? Is there some way to prove that this is impossible? Also, what if there is no linearization as such - what if, when you call the superclass, it actually calls ALL the parents, not just one? > > I don't know whether you're mistaken or utterly arrogant. > > Do you think they are the only two choices? Are you such a contrarian > that you refuse to even consider that I might be right? You see the problem of the excluded middle now. Can you recognize when you're making it yourself? ChrisA _______________________________________________ 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/6FHB6EJWQIEKFEMXQOHJ7B7HSYEP7FPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
