Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix (U)IntPtr construction#1861

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
filmor merged 6 commits intopythonnet:releasefromfilmor:fix-intptr-conversion
Jul 11, 2022

Conversation

filmor
Copy link
Member

What does this implement/fix? Explain your changes.

Allows creating anIntPtr 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:

if(type.IsPrimitive||type==typeof(string))
{
if(Runtime.PyTuple_Size(args)!=1)
{
Exceptions.SetError(Exceptions.TypeError,"no constructors match given arguments");
returndefault;
}
BorrowedReferenceop=Runtime.PyTuple_GetItem(args,0);
if(!Converter.ToManaged(op,type,outvarresult,true))
{
returndefault;
}
returnCLRObject.GetReference(result!,tp);
}

Does this close any currently open issues?

#1116

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 toAUTHORS
  • Updated theCHANGELOG

@filmorfilmor mentioned this pull requestJul 8, 2022
23 tasks
@filmorfilmor changed the titleAdd unit tests for (U)IntPtr conversionsFix (U)IntPtr conversionsJul 8, 2022
@filmorfilmor changed the titleFix (U)IntPtr conversionsFix (U)IntPtr constructionJul 8, 2022
@filmorfilmorforce-pushed thefix-intptr-conversion branch from54e5a7d to1c21526CompareJuly 8, 2022 18:41
@filmorfilmor requested a review fromlostmsuJuly 9, 2022 14:05
@filmorfilmor marked this pull request as ready for reviewJuly 9, 2022 14:05
@filmor
Copy link
MemberAuthor

I'm not entirely happy with this, yet. I think we might want to do the special-casing inClassObject instead, like it's done for enums and bigints. Thoughts?

@lostmsu
Copy link
Member

Re: IntPtr

Why can't we just treat IntPtr as non-primitive type? Then its constructor will be invoked by normal means.

@lostmsu
Copy link
Member

Maybe we should have an explicit set of types for which this constructor masking behavior should be used, instead of relying onIsPrimitive which was created for a totally different purpose.

@filmor
Copy link
MemberAuthor

Re: IntPtr

Why can't we just treat IntPtr as non-primitive type? Then its constructor will be invoked by normal means.

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.

@lostmsu
Copy link
Member

lostmsu commentedJul 11, 2022
edited
Loading

apparently calling a cobstructor on a primitive type after it has been created "uninitialised" is a no-op

@filmor this would be highly problematic depending on what types this behavior applies to. If it is justIsPrimitive types, then we just need to adjust handling explicitly. However, if it is the case for any value types, we are in trouble.

UPD. Just checked rc2 for the record, values types in general seem fine:TimeSpan(3, 2, 1).ToString() prints'03:02:01'.

IntPtr gives "TypeError: No match found for given type params"

@filmorfilmorforce-pushed thefix-intptr-conversion branch 2 times, most recently froma6cdc35 to43f748bCompareJuly 11, 2022 12:23
@filmorfilmorforce-pushed thefix-intptr-conversion branch from43f748b toae5e074CompareJuly 11, 2022 12:30
@filmorfilmor merged commit332f8e7 intopythonnet:releaseJul 11, 2022
@filmorfilmor deleted the fix-intptr-conversion branchJuly 11, 2022 12:38
@lostmsu
Copy link
Member

lostmsu commentedJul 11, 2022
edited
Loading

@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))
Copy link
Member

@lostmsulostmsuJul 11, 2022
edited
Loading

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 forIntPtr constructor call with this path (e.g. parameter is neither CLR object nor Pythonint)

Copy link
MemberAuthor

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.

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

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

dead TODO?

Copy link
MemberAuthor

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.

@filmor
Copy link
MemberAuthor

@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.

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. :)

@filmorfilmor mentioned this pull requestSep 17, 2022
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@lostmsulostmsulostmsu left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@filmor@lostmsu

[8]ページ先頭

©2009-2025 Movatter.jp