-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Unify Python 2 & 3 py::module constructor, and make contructor with pre-allocated PyModuleDef private #2534
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
Merged
henryiii
merged 1 commit into
pybind:master
from
YannickJadoul:module-private-constructor
Oct 2, 2020
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
Is the
new PyModuleDef()
actually useful? If this is used there will be leak check errors again. — I'm just trying to understand. I intentionally side-stepped / deferred this question in #2413 (see "potential follow-up" note in top-level comment), to not have it block the straightforward solution, but if we invest more time to get things as clean as possible, the question seems important to consider.Uh oh!
There was an error while loading. Please reload this page.
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.
Good point; I don't really know. Things worked like that before, so I just kept it, but it's worth an investigation.
Is there any point to constructing a module without
PYBIND11_MODULE
? Nested submodules are created withmodule_::def_submodule
, modules are imported throughmodule_::import
, and extra embedded modules are added throughPYBIND11_EMBEDDED_MODULE
. So I don't know if there a valid use case for constructing a loose, non-nested, standalone module which is not the top-level module of an extension?If not, maybe the
module
constructors ought to just be private (providing access throughpybind11::detail::create_module
for internal purposes)?If there is a use case and this is used, we might not want to break old code? Correct me if I'm wrong, but the
new
vs.static
doesn't actually matter a lot, and is just to shut up the leak detectors? In practice, both astatic
PyModuleDef
as well as anew
-allocated one will just stay alive for as long as Python is running.So I saw #2413 more as a way to make valgrind and other sanitizers happy (which is a perfectly valid thing to do; don't get me wrong! :-) ), rather than plugging an actual leak.
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.
A quick update: some pybind11 unit tests fail if I make the change suggested in the #2413 top-level comment.
But I will run our global testing anyway, to see if there are any other uses of
module_::module_
.For easy references, this is the change I'm trying:
Yes, that's 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.
@YannickJadoul No failures!
That observation strongly suggests that it's very unlikely that anyone outside needs the public
module_::module_
constructor. I think if we can fix up the unit tests we can make it private; my suggestion is to try that after the 2.6.0 release is out.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.
There are only two call sites that need the
module_::module_
constructor: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.
Great news! Let's go back a bit in history and check if there are any related issues or PRs that would say otherwise. If not, I like the idea of just making this constructor private and having access through
pybind11::detail::create_top_level_module
! :-)I am in the middle of moving, though, so it'll be only this weekend or early next week.
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.
Any reason to wait for this until after 2.6.0, though? My initial suggestion would be to merge the current state of this PR (as to nót release a change to the public API that was introduced in #2413, and that would be annoying to deprecate again, later), and potentially add a deprecation warning to the public
module_
constructors. Once people start using it, we can see if we get complaints and revert the deprecation, or go on with it?But especially about the latter part, I can be persuaded to change our approach. I would really like to úndo the change to the public API before officially releasing it, though; your tests have given me a bit more confidence that this should actually be possible :-)
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.
My only concern is that it adds a little bit of complexity, but I'm OK if you feel merging this is best, on the way to making the entire interface private.