the proposed patch provides an implementation of a new ‘import’ command for LLDB, based upon Python commands. an example usage is:
(lldb) script import importcmd
(lldb) command script add -f importcmd.pyimport_cmd import
(lldb) import /Users/user/Documents/demo1.py
(lldb) script demo1.test_function(1)
there is an included test case that checks for correctness of this new command by importing some Python script files and using the resulting modules
plus, this fixes a minor issue where the custom Python commands defined for the functionalities/command_python/ test case would not be cleaned up if the test case itself failed
Any feedback on this is most welcome.
importcmd_patch.diff (7.66 KB)
I checked in the cleanup patch for TestCommanPython.py.
As for the ‘import’ command, can you rework the patch to rely on os.sep instead of ‘/’
as the pathname components separator?
This is a nice convenience, I was a little worried at first because I want to try to avoid introducing top-level name commands when not necessary... I want to keep that namespace as clean as possible so people can use it for shortcuts.
On thinking a bit, it seems more logical to me if the same functionality was done through "command script import"; that could do whatever the current script language does to import a module into the scripting language.
It is also pretty consistent with having "command script add/delete/etc..."
If you follow this through further, if we have control of it we could also make some convention like if you do:
def __lldb_init_for_interpreter (lldb_interpreter):
we would call this and pass in the LLDB interpreter that was doing the import. Then you could put your package's "command script add" commands in there. That way you could make up modules that you import and they would add all their commands to the LLDB interpreter they were being imported into...
We could also add commands to set the PYTHONPATH, etc, like:
command script import --path-component ~/.lldb_python my_script...
This is more work, so I have no problem with adding the example for now. But if we do more work on it, I argue more for it's going into "command script import..."
I’m not sure whether the TestImport.py test case belongs under test/python_api at all?Anyway, you should not make the test case skipUnless it’s a Darwin platform.
I shall check in the examples patch for the time being, since the test patch and the examples/customization/import-python
patch are a little bit redundant? What do you think?
I think your idea makes sense. I will resubmit the test case once I finish working on a patch to implement command script import, as in the previous emails.