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 Python list, 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 still IEnumerable<> 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 for ICollection<>, but one step after another :)

@filmor what about functions, that do len(arg)?

That is the second paragraph of my comment ;)

IEnumerable doesn't allow you to do an efficient len either, that's what ICollection<> is for and we would have to implement at least sq_len then.

@filmor I meant that previously when you pass a List<T> to a Python function, that uses len(lst) it would work, but if List<T> is no longer converted to list, that will stop working.

List<T> implements ICollection<T> which has a Count property which should in turn be used to implement the sq_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 implement sq_length too before the next release?

This PR is a draft, I plan to work on it until all tests pass. If that means implementing sq_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 .NET IEnumerable as an iterable and ICollection as a sequence from Python catches most use cases of the conversion without breaking code like l = obj.GetCSharpList(); obj.CallWithCSharpList(l).

The rationale is the huge number of issues related to the automatic conversion. Just being able to use a .NET IEnumerable as an iterable and ICollection as a sequence from Python catches most use cases of the conversion without breaking code like l = 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)

class RawListEncoder: RawProxyEncoder {
  public override bool CanEncode(Type type)
    => type.IsGenericType && type.GetGenericTypeDefinition() == typeof(List<>);
}

PyObjectConversions.RegisterEncoder(new RawListEncoder());

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.