-
Notifications
You must be signed in to change notification settings - Fork 717
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
Fix (U)IntPtr construction #1861
Conversation
54e5a7d
to
1c21526
Compare
I'm not entirely happy with this, yet. I think we might want to do the special-casing in |
Re: IntPtr Why can't we just treat IntPtr as non-primitive type? Then its constructor will be invoked by normal means. |
Maybe we should have an explicit set of types for which this constructor masking behavior should be used, instead of relying on |
Because then it's always default constructed, apparently calling a cobstructor on a primitive type after it has been created "uninitialised" is a no-op. I can check again, though I'm quite certain that that was among the first things I've tried. |
@filmor this would be highly problematic depending on what types this behavior applies to. If it is just UPD. Just checked rc2 for the record, values types in general seem fine:
|
a6cdc35
to
43f748b
Compare
43f748b
to
ae5e074
Compare
@filmor this PR was rushed. There are few artifacts of development left in the final code, the latest commits never reviewed, and the earliest not reviewed completely. This would be OK if there was no active response for a few days, but simply bypassing review on new code is not a good idea. |
} | ||
} | ||
|
||
if (result == null && !Converter.ToManaged(op, type, out result, true)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a test for IntPtr
constructor call with this path (e.g. parameter is neither CLR object nor Python int
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you expect to happen? It fails to convert, this is essentially the "old" code path. I'll add the test, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@filmor actually, nothing specific. Just want to ensure it does not error in a weird way and the error is actually helpful.
/// <param name="args">Constructor arguments</param> | ||
private static NewReference NewPrimitive(BorrowedReference tp, BorrowedReference args, Type type) | ||
{ | ||
// TODO: Handle IntPtr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dead TODO?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I'll remove it.
It might have been a bit rushed, but that was mostly because I wanted to tackle the other remaining issues (regressions from the constructor refactor) and get a new rc out soon for people to test with. This one would have actually bitten myself for a change if we had released this as stable. :) |
What does this implement/fix? Explain your changes.
Allows creating an
IntPtr
from Python. This is currently impossible, because we rely on automatic conversion (asIntPtr
is a primitive type) while we don't actually implement one for this type (rightly so!).The relevant code section is:
pythonnet/src/runtime/Types/ClassObject.cs
Lines 73 to 89 in 87d4db9
Does this close any currently open issues?
#1116
Any other comments?
...
Checklist
Check all those that are applicable and complete.
AUTHORS
CHANGELOG