Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement IConvertible on PyObject #1762

Merged
merged 1 commit into from Apr 11, 2022
Merged

Conversation

filmor
Copy link
Member

@filmor filmor commented Apr 10, 2022

What does this implement/fix? Explain your changes.

Implements the IConvertible interface for PyObject instances.

Does this close any currently open issues?

Should fix #1755.

Any other comments?

...

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
  • Ensure you have signed the .NET Foundation CLA
  • Add yourself to AUTHORS
  • Updated the CHANGELOG

@lostmsu
Copy link
Member

lostmsu commented Apr 10, 2022

.NET team now avoids IConvertible: dotnet/runtime#936 (comment)

@lostmsu
Copy link
Member

lostmsu commented Apr 10, 2022

See also dotnet/runtime#62022

@filmor
Copy link
Member Author

filmor commented Apr 10, 2022

It doesn't look like there is an alternative yet, though, right? And I also don't think that they are actually going to drop the interface, they are just not extending it for new primitive types, which have no representation in Python anyway.

@lostmsu
Copy link
Member

lostmsu commented Apr 10, 2022

@filmor the new Half type does not implement IConvertible though it is nearly identical to Single and Double. So I guess it is kinda deprecated (not that I completely agree with everything .NET team does).

@@ -230,5 +230,7 @@ public string ToString(string format, IFormatProvider formatProvider)
using var _ = Py.GIL();
return ToBigInteger().ToString(format, formatProvider);
}

public override TypeCode GetTypeCode() => TypeCode.Int64;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, this is wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs are a bit unclear on this function. I used this as an "should almost always work" value, the InvalidCastException might still be thrown if the conversion fails. We could drop the GetTypeCode overrides entirely and just return TypeCode.Object if you'd prefer that.

Copy link
Member

@lostmsu lostmsu Apr 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't say for others, just for this one. Honestly, not sure if anyone ever uses this. Our own code assumes TypeCode.Int64 refers to System.Int64, so removing might be a good idea.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow. GetTypeCode is supposed to be a hint that allows you to write a switch like

switch (convertible.GetTypeCode()) {
    case TypeCode.Int64:
        return Convert.ToInt64(convertible);
}

It doesn't mean that the object is a System.Int64 already.

Copy link
Member

@lostmsu lostmsu Apr 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You seem to be correct on that. Still not sure Int64 is valid for this specific case, but float and string probably are. I am fine either way though. I don't think we will get people complaining about this returning Int64 any time soon.

@lostmsu lostmsu merged commit 80dc9f0 into pythonnet:master Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Python int type is translated to pyInt when passed as a .net Dictionary value only in 3.x version
2 participants