point_in_objectp working#54
Closed
ChristopherHogan wants to merge 3 commits intoNanoComp:masterfrom
ChristopherHogan:chogan/pnt_in_obj
Closed
point_in_objectp working#54ChristopherHogan wants to merge 3 commits intoNanoComp:masterfrom ChristopherHogan:chogan/pnt_in_obj
ChristopherHogan wants to merge 3 commits intoNanoComp:masterfrom
ChristopherHogan:chogan/pnt_in_obj
Conversation
Collaborator
|
My concern is that SWIG wouldn't create nice Python proxy objects for the C types in |
Contributor
Author
|
Okay. I'll continue with this approach. Thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR isn't to merge, but to request feedback for the path I'm taking. I can successfully write
in python and it will call
point_in_objectp(some_point, some_object), returning the correct result, but something seems off about this approach. Does it make sense to build up a pure pythonSpherejust to tear it apart in the typemap? It seems like we should just wrapctlgeom-types.hand then do something likeThen we wouldn't even need a typemap because the python objects would be SWIG proxy objects with types that correspond to the C types. I think I'm still unclear on exactly which header files we want to create python wrappers for.
@stevengj @HomerReid @oskooi