Disable implicit conversion from PyFloat to .NET integer types

[lostmsu]

What does this implement/fix? Explain your changes.

Previously, when a floating point value was passed to .NET parameter of integer type, it would be silently truncated. After this change it would no longer be permitted to pass a floating point value to integer parameter.

Does this close any currently open issues?

#1342

Any other comments?

I removed poorly-behaved PyLong_As* functions, as they would always implicitly convert argument to integer type, which in most cases is undesired behavior. Instead, to avoid roundtrips, PyLong_AsSize_t is used in most cases. The only exception is Int64 which on 32 bit platforms is larger than size_t, so PyLong_AsLongLong function is used after explicit check for PyLong.

Draft because it depends on C# 9, which is not yet ready.

Checklist

Check all those that are applicable and complete.

• Make sure to include one or more tests for your change
• If an enhancement PR, please create docs and at best an example
• Updated the CHANGELOG

[tminka]

test_uint64_conversion should similarly raise a TypeError here

[christabella]

In what sense is C# 9 not ready? It would be great if this fix was merged, since that would unblock other issues e.g. #1040

[lostmsu]

@christabella @tminka if we bump version now, users of many older Mono builds will be unable to install pythonnet master due to lack of C# 9 support. This will no longer be a problem after merging https://github.com/losttech/pythonnet/commits/features/VersionIndependent , which will allow building single Python.Runtime.dll for all Python versions (so they don't have to build it).

The problem is this branch relies on a new C# feature - unmanaged function pointers, which is broken in the latest .NET Core SDK C# compiler. The fix is up in Roslyn's master, but has not been released yet.

[filmor]

@lostmsu The only C# 9 feature you are using here is nint, isn't it? As far as I understood this, the feature doesn't require help from the CLR, so it should work with older Mono versions as well. @BadSingleton @benoithudson Could you verify that this branch still works with the Mono version you are using?

[lostmsu]

I expect older Mono versions to have old C# compiler, which simply won't recognize nint.

[benoithudson]

I don't know what this is about exactly. For Unity, if we can target NET Standard 2.0 we're good. We don't use the Unity mcs to compile anyway, we ship this code as DLLs.

Helpfully, Microsoft now tells you which version of Unity supports which standard.
https://docs.microsoft.com/en-us/dotnet/standard/net-standard

[filmor]

We don't compile this project with the Mono C# compiler either, we expect a .NET Core SDK to be installed nowadays. This just bumps the required SDK version to 5.0, I think.

[filmor]

@lostmsu Since this passes tests, I'd vote we merge it but keep the bumped requirement in mind.

[lostmsu]

@filmor heads up, MS just released VS 16.9 Preview 3 along with a new .NET SDK Preview, and the blocking issue I mentioned above appears to be fixed there. I should resume work on building a version independent DLL by the next sync.