Message11591

Author zyasoft
Recipients bmvanwyk, tomluk, zyasoft
Date 2017-09-11.22:26:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1505168782.39.0.957299630177.issue2445@psf.upfronthosting.co.za>
In-reply-to
Content
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 https://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#isAssignableFrom(java.lang.Class)
History
Date User Action Args
2017-09-11 22:26:22zyasoftsetmessageid: <1505168782.39.0.957299630177.issue2445@psf.upfronthosting.co.za>
2017-09-11 22:26:22zyasoftsetrecipients: + zyasoft, tomluk, bmvanwyk
2017-09-11 22:26:22zyasoftlinkissue2445 messages
2017-09-11 22:26:21zyasoftcreate