-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add custom_type_setup
attribute
#3287
Conversation
1cd90e3
to
c3d0c0e
Compare
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.
Initially the suggested changelog entry made me wonder: does custom_type_setup
exist already? Is this PR enhancing the functionality?
But no, it's new.
How about:
pybind11::custom_type_setup
was added, for customizing the PyHeapTypeObject
corresponding to a class_
, which may be useful for enabling garbage collection support, among other things.
Thanks, I updated the "suggested changelog" per your suggestion. An alternative is to add direct support for garbage collection, similar to the other protocols. But still I think |
8e0d428
to
dc4fbfe
Compare
dc4fbfe
to
480dd77
Compare
480dd77
to
7dd511e
Compare
e295d8c
to
e06f7ca
Compare
All tests pass now. |
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 believe this is a useful addition, although I also wonder if this will lead to N
almost correct implementations for adding GC support (in other repos), instead of 1
firmly correct implementation (in this repo). — On balance I'm coming down on the side of "let it grow and maybe clean up later" vs slipping into over-engineering.
} | ||
|
||
R (*erased_fn_)(void *, Arg...) = nullptr; | ||
const void *erased_obj_; |
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.
type_erased_obj_
?
If that's correct, I'd definitely spend the extra few characters for clarity.
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.
Done.
e06f7ca
to
6863368
Compare
It looks like all tests now pass --- the one failure was just a spurious one. |
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'd feel much more comfortable with this PR if the documentation had a pointer to tested code elsewhere, and if we either reuse std::function
, or have measurements to show that the function_view
optimization is worth the extra code.
But I think it'll be best to first let @henryiii and @Skylion007 weigh in. I'm OK with this PR as-is if it gets support from a majority.
The current documentation does not do this. We probably should use include markers and test the documentation examples that way, but we don't, and I don't think we should change styles in the middle of an unrelated PR. We in general have to be careful changing any public interface, and this makes that a public interface, so the docs shouldn't bit-rot too fast. |
cdfbcf8
to
f808a98
Compare
Note: Tests are now failing on Windows, due to an unrelated warning, presumably due to a compiler upgrade on github actions. |
The last build on master compiled after this, with no errors. Also Appveyor also failed. Notice it's only 2.7 failing (yuck). |
This is the error I'm seeing on both AppVeyor and github actions:
|
8df806b
to
de5147b
Compare
de5147b
to
a0145fa
Compare
Okay, all tests are passing now. |
a0145fa
to
2d4e528
Compare
This allows for custom modifications to the PyHeapTypeObject prior to calling `PyType_Ready`. This may be used, for example, to define `tp_traverse` and `tp_clear` functions.
2d4e528
to
74af2d8
Compare
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.
Looks good to me.
Potentially adding function_view
in another PR sounds fine, although only if we can show that the extra code has some measurable benefit.
Is there anything left to do here? |
@henryiii, @Skylion007, are you OK with this PR as it is now? |
Thanks @henryiii ! |
This allows for custom modifications to the PyHeapTypeObject prior to
calling
PyType_Ready
. This may be used, for example, to definetp_traverse
andtp_clear
functions.Description
Suggested changelog entry: