-
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
Added function for reloading module #1040
Conversation
Edit: two important things are missing: documentation, and a test case. |
Yep, will try and finalize this! |
43437b0
to
478091e
Compare
I've tried setting up a test case to cover this, but I'm not completely happy with it.. I think this change is relevant when importing modules from file, so I basically print a temporary file which I import, call, change, reload and then call again according to the code below. The ugliness is that in order for the pycache to detect that the py file has been updated I had to add a sleep of at least 500ms. What do you think? The whole idea with temporary files is not very pretty so maybe you have a better idea on how to test this. Of course the temp files should be cleaned up properly as well upon test termination.
|
Edit (again): I see Catch inside the test embed directory. If you wanted to test this is in the normal pytests, you could simply put this in a function and then py::print the values and then check them from python. |
Thanks for the input, and I think it makes most sense to test this from the C++ side with the Catch tests. I pushed a suggested test so you can see where it fits in. The sleep is not very pretty, an option would be to clear the |
Instead of auto os = py::module::import("os");
auto stat = os.attr("stat")(module_file);
const auto access_time = stat.attr("st_atime").cast<double>();
const auto mod_time = stat.attr("st_mtime").cast<double>();
os.attr("utime")(module_file, py::make_tuple(access_time, mod_time + 1)); |
@@ -2,6 +2,9 @@ | |||
#include <catch.hpp> | |||
|
|||
#include <thread> | |||
#include <fstream> | |||
#include <cstdio> |
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.
Why < cstdio>
?
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 thought I needed it for std::remove()
but it seems to build fine without it.
I tried this but I believe it has more to do with the timestamp of the cached .pyc file. Changing the timestamp of the .pyc file in the same manner didn't help though so I'm not quite sure about the mechanics behind However, I think I have a better solution in https://docs.python.org/2/library/sys.html#sys.dont_write_bytecode to avoid the .pyc files altogether. I'll push a new version now. |
You need to |
Nice, no more 1 second delay. I didn't know cache file generation could be disabled at runtime. That's very handy. This looks good to me! |
Merged, thanks @lathen! |
I found my way by virtue of the documentation. I have an issue where i am trying to call some Python in a C++ plugin within a third party app called Nuke by the company Foundry. In their Python interpreter I can run the pybind11 pytest suite and everything passes OK. But if I do something as simple as py::object ospy = py::module::import("os"); It results in a gdb traceback as follows:
Do you have any suggestions on something I could test? I think I will get in contact with the Foundry about it too. |
I think this thread may be useful |
I tried embedding the interpreter using pybind11 in an application where we want to do on-line processing using Python combined with C++. The processing runs iteratively, so I needed a way to reload the imported modules to allow the user to change the Python code between different runs. This PR simply adds a wrapper to PyImport_ReloadModule() and seems to solve the problem nicely.
If this seems relevant to merge in I can try and finalize it with tests and docs.
I'm not so familiar with the fancy C++ stuff so I'm not sure that the final
*this = reinterpret_steal<module>(obj);
is good.