Author zyasoft
Recipients bmvanwyk, tomluk, zyasoft
Date 2017-09-11.22:26:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
So likely the solution here is to add a type unification step to PyJavaType#handleMroError, such that if for some pairing of types T and U, if type T is reported to conflict with type U, but T is a subclass or subinterface of U, then ignore as a MRO conflict error (because it's not). For some reason, the MRO conflict detection reports false positives, and we already have one workaround for this with respect to __iter__. I suspect these all seem to revolve around methods that are part of the Python integration support seen in JavaProxyList, etc. In particular, remove was added to this support in 2.7; it was not part of 2.5, so this adds further evidence to why this conflict now exists.

This type test can be readily done with
Date User Action Args
2017-09-11 22:26:22zyasoftsetmessageid: <>
2017-09-11 22:26:22zyasoftsetrecipients: + zyasoft, tomluk, bmvanwyk
2017-09-11 22:26:22zyasoftlinkissue2445 messages
2017-09-11 22:26:21zyasoftcreate