All CLA requirements met.

Thank you for taking this up again.

• Support decimal, timespan, datetime, implicit, and nullable conversions (QuantConnect#1, QuantConnect#8, QuantConnect#10, QuantConnect#14, QuantConnect#15, QuantConnect#25)

• Use Float in Python for Decimal conversion (Performance improvement QuantConnect#19)

I'm still very much against doing these conversions without a way to shut them off (while I agree that they might be good defaults). We nowadays have a system to implement additional conversions and configure them at runtime, codecs for the types you listed would be appreciated: https://github.com/pythonnet/pythonnet/wiki/Codecs:-customizing-object-marshalling-between-.NET-and-Python

• Some logging on boot up (QuantConnect#34)
  Straight Console.Writes will not get accepted. Trace logging might be, as long as it doesn't pull in additional dependencies (e.g. https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.trace?view=net-5.0)

• Support List conversion (QuantConnect#37)

This might also be implementable as a codec. I'll have a closer look

• AssemblyManager Cache (Performance improvement QuantConnect#38)

This looks nice, needs a separate PR.

• Generic Util race condition fix (QuantConnect#38)
  Is this still applicable?

• Support KeyValuePairEnumerable Objects (QuantConnect#42)

Also looks like a codec candidate.

• MethodBinder changes to allow implicit conversion. This one was particularly tricky and seemed impossible to patch together with the MethodBinder.cs in the root. Unfortunately it involved tearing apart a lot of it and rebuilding only what was needed. It may be possible to refactor this to look more like the root and still pass our tests. ( 58d5df0 , 44e089a , 108eacf , 6379568 , 9f2796a )

This would definitely need a separate PR. You could start with a PR that adds the tests.

• Revert PythonNet PR Wrap returned objects in interface if method return type is interface #1240 ; this PR broke fetching interface derived classes data members that weren't defined in the interface. ( ed6ab18 )

Could you give a concrete example of what is failing now? Can it be mitigated using the __implementation__ member?

• Converting PyObject to Int fix; this reflects the way PythonNet used to convert values to Int32, 64, unsigned etc, with PyNumber_Long but still keeps the use of Runtime.PyLong_AsSignedSize_t to finish the conversion. The bug that discovered this was trying to convert a Python float to int, this used to work but was failing until this refactor. Reference the added test in bd94e49. ( d87584b )

This looks good, can you create a PR for this one?

@filmor @C-SELLERS I sent an email to the pythonnet group about issues coming from #1240. @lostmsu suggested some things (here are 4 and 5 of his suggestions):

"
4. IronPython apparently allows explicit interface implementations to be called (instead of returning interface-wrapped instances), if there’s no conflict with regular methods. Perhaps we should consider this as an option.
5. Alternatively, we can keep wrapped instances, but allow to resolve public members too if the method is not found in the interface. I like this option better than 4, because actual type of an element in ISomething[] won’t change behavior of invoking interface member. It might still affect hasattr, but this is somewhat expected."

I think (4) is something like a revert.

Converting PyObject to Int fix; this reflects the way PythonNet used to convert values to Int32, 64, unsigned etc, with PyNumber_Long but still keeps the use of Runtime.PyLong_AsSignedSize_t to finish the conversion. The bug that discovered this was trying to convert a Python float to int, this used to work but was failing until this refactor. Reference the added test in bd94e49. ( d87584b )

This looks good, can you create a PR for this one?

The old behavior (implicit conversions between numerical types like in the new test) should not be restored. I suggest you require explicit conversion via int(decimal_value) on Python side or a similar method. Implicit conversion is dangerous (especially in finance).

I'm still very much against doing these conversions without a way to shut them off (while I agree that they might be good defaults). We nowadays have a system to implement additional conversions and configure them at runtime, codecs for the types you listed would be appreciated: https://github.com/pythonnet/pythonnet/wiki/Codecs:-customizing-object-marshalling-between-.NET-and-Python

We also have a repository for community-contributed codecs: https://github.com/pythonnet/codecs

Thank you guys for your feedback!

I plan to look into these when permitted and hope to start PR'ing the changes individually that can work! I definitely need to take some time and look at the codec setup you guys have, I wasn't quite sure how it worked and I didn't really understand the wiki either. I'll search for some examples and test it out and see if our conversions can be done that way.