Message12444

Author jeff.allen
Recipients bmvanwyk, jeff.allen, tomluk, wfouche2, zyasoft
Date 2019-04-19.17:36:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1555695390.21.0.971058883459.issue2445@roundup.psfhosted.org>
In-reply-to
Content
I've restructured handleMroError for readability, and I see what it does to fix the C3 merge conflict, which is simple enough. https://hg.python.org/jython/rev/262428b2c51a

I have no idea why we go looking for same-named methods at this point. It does nothing to solve the merge problem, which is structural amongst classes irrespective of their methods.

I understand why conflicting definitions arriving through different bases might be an issue. I don't see why we only check for it once C3 MRO generation has stalled. If it is necessary at all, why don't we do it unconditionally when (re-)calculating the MRO?

In an interesting simple case, handleMroError is called for org.python.util.PythonInterpreter, and the state is:
[java.lang.AutoCloseable, java.lang.Object, object]
[java.io.Closeable, java.lang.AutoCloseable, java.lang.Object, object]
[java.lang.Object, object]
[java.lang.AutoCloseable, java.io.Closeable, java.lang.Object]

Neither type in conflict here [<type 'java.lang.AutoCloseable'>, <type 'java.io.Closeable'>] has a .modified list, but on return each has a .conflicted list accusing the other.

Now Closeable extends AutoCloseable, so we might as well have declared that PythonInterpreter implements just one of those. In that case we would never have called handleMroError. But then .conflicted would not be set on Closeable and AutoCloseable. If the state of these two type objects varies in response to an inconsequential (compile-time) change in a third class, we must be doing something wrong.

The only other uses of .conflicted and .modified (in Java, anyway) are in type___setattr__ and type___delattr__, where .conflicted is consulted (but not updated) and .modified consulted and updated with the name added/deleted.

handleMroErrorappears to be the *only* place we set .conflicted, and whether or not we do so appears to be a matter of chance unrelated to the possession of conflictingly-named methods. 
It leaves me wondering what could possibly go wrong if we simply removed this whole test and the .conflicted attribute.
History
Date User Action Args
2019-04-19 17:36:30jeff.allensetmessageid: <1555695390.21.0.971058883459.issue2445@roundup.psfhosted.org>
2019-04-19 17:36:30jeff.allensetrecipients: + jeff.allen, zyasoft, tomluk, bmvanwyk, wfouche2
2019-04-19 17:36:30jeff.allenlinkissue2445 messages
2019-04-19 17:36:29jeff.allencreate