Just want to confirm if we are to bump up major version with it. Seems like a non-trivial change, that might break a lot of things, that are working now.

It is not immediately obvious from this change, but if I used to pass an array to a parameter, that expects Pythonlist, would this no longer work anymore?

I'm trying to keep the amount of changes in behaviour to a minimum. I'm not going to bump the major version (i.e. this will not be 3.0) but instead the minor version 2.5 as I've had enough of the "lists behave weirdly" kind of issues we are seeing since this was introduced.

.NET array objects are stillIEnumerable<> and thus will keep being iterable, so for Python functions that don't (wrongly) check the type explicitly this will still work. We can as a further step also implement the Python Sequence Protocol forICollection<>, but one step after another :)

@filmor what about functions, that dolen(arg)?

That is the second paragraph of my comment ;)

IEnumerable doesn't allow you to do an efficientlen either, that's whatICollection<> is for and we would have to implement at leastsq_len then.

@filmor I meant that previously when you pass aList<T> to a Python function, that useslen(lst) it would work, but ifList<T> is no longer converted tolist, that will stop working.

List<T> implementsICollection<T> which has aCount property which should in turn be used to implement thesq_length slot of the sequence protocol (https://docs.python.org/3/c-api/typeobj.html#sequence-object-structures)

@filmor "should be used" but not "already used". Are you planning to implementsq_length too before the next release?

This PR is a draft, I plan to work on it until all tests pass. If that means implementingsq_length, then that's what I am going to do.

What's the rationale for this please?

The rationale is the huge number of issues related to the automatic conversion. Just being able to use a .NETIEnumerable as an iterable andICollection as a sequence from Python catches most use cases of the conversion without breaking code likel = obj.GetCSharpList(); obj.CallWithCSharpList(l).

The rationale is the huge number of issues related to the automatic conversion. Just being able to use a .NETIEnumerable as an iterable andICollection as a sequence from Python catches most use cases of the conversion without breaking code likel = obj.GetCSharpList(); obj.CallWithCSharpList(l).

OK, thanks. It would be nice to close down a bunch of issues.

Any chance of getting a look at those issues?

@filmor@lostmsu Even if we drop it if we provide a codec (see 1022) that is not registered by default users can easily opt back into the current behavior by registering it themselves.

@filmor First of all, thanks for providing such a great library!

Do you think this can go in as part of the 2.5 release? I see it's not in the RC, but would love to see this fixed.

@mmisol Sorry, 2.5 is a minor release, we can't break the API even though it would be an improvement.

@mmisol injecting a no-op codec will allow you to override this behavior with 2.5:https://github.com/pythonnet/pythonnet/blob/master/src/runtime/Codecs/RawProxyEncoder.cs

E.g. (might contain errors)

classRawListEncoder:RawProxyEncoder{publicoverrideboolCanEncode(Typetype)=>type.IsGenericType&&type.GetGenericTypeDefinition()==typeof(List<>);}PyObjectConversions.RegisterEncoder(newRawListEncoder());

See also an example from Python side:f707698#diff-f8910e440ff4d17505744bd4c7016697R706

I think this has been superseded in 3.0 branch. These default conversions are no longer enabled but can be reimplemented with codecs.