@amos402 @filmor @lostmsu please review. I think this PR may help with our implicit conversions of lists.

Haven't done a full pass yet, but instead of doing "levels" you can just have 3 decoders, and register them in order from highest priority to lowest priority. E.g.

Register(ListEncoder.Instance);
Register(CollectionDecoder.Instance);
Register(IterableDecoder.Instance);

Also, please, do not dump all classes in the encoder file.

@lostmsu I can change the physical layout but wanted to make sure I was on the right track first. I like the idea of having multiple codecs with priority, that way clients can choose which encoder they need. I'll work on that.

This is related to #912

@lostmsu While the unit tests work when I tried it from python I realized (again) that CanDecode is based on the type rather than the instance, so I changed that. Also I added some python tests

If you're considering the performance improvement, this branch may help you.
https://github.com/joonhwan/pythonnet/tree/fast-call
It's an ancient branch I deleted a long time ago, my current internal branch has far more than that.
You can do some performance tests, like method calls, properties get-set, etc, you will see that the branch above has a lot faster than the master now. The simple points are avoiding any MethodInfo.Invoke, use pre-created delegates instead, prevent any boxing or unboxing if you can. After that, if you want a higher than it, code generation is an option.

The codec has some design points can improve:

• Decode, Encode used object, which means it may occur boxing.
• When it decode/encode an object, it has iteration operations which can be avoided, or use some hash table for getting the coder directly.
• For achieving no reflection calling, no boxing or unboxing, you may need to redesign the method calling mechanism just like I did, you can check the methodobject.cs on the above branch.

If you're considering the performance improvement, this branch may help you.
https://github.com/joonhwan/pythonnet/tree/fast-call
It's an ancient branch I deleted a long time ago, my current internal branch has far more than that.
You can do some performance tests, like method calls, properties get-set, etc, you will see that the branch above has a lot faster than the master now. The simple points are avoiding any MethodInfo.Invoke, use pre-created delegates instead, prevent any boxing or unboxing if you can. After that, if you want a higher than it, code generation is an option.

The codec has some design points can improve:

• Decode, Encode used object, which means it may occur boxing.
• When it decode/encode an object, it has iteration operations which can be avoided, or use some hash table for getting the coder directly.
• For achieving no reflection calling, no boxing or unboxing, you may need to redesign the method calling mechanism just like I did, you can check the methodobject.cs on the above branch.

Thank you for sharing! I haven't measured performance issues but now I know what to try if I do.

@lostmsu would you mind reviewing this again? I resolved all of your previous comments

@koubaa sure, but can't do it until Saturday.

@lostmsu I'll look to enable these by default (and handle issues associated w/that) in a later PR

@lostmsu I rebased to fix the merge conflict. Is there anything else needed before this can be merged?

@koubaa do you plan to finish this PR? The open issues that this would close include
#909 #601 #962

@christabella I have been waiting for @lostmsu to merge it

@lostmsu I rebased the changes to resolve the conflicts. Is there anything needed before this can be merged?

@koubaa @christabella once the CI tests pass, I can take this. Note, however, that I have a different approach in mind, based on mixins and base class faking (a feature I have in my fork, that is yet to be upstreamed, its implementation is relatively involved). So this will probably be replaced before 3.0 is released.

@lostmsu the CI is fixed