-
Notifications
You must be signed in to change notification settings - Fork 33
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
Feature/lean kernel exposure #154
Conversation
Lean kernel exposure
In the case of conflicting object (modules, classes, functions, variables) names, the `tudatpy` object will be kept. Thus: - `tudatpy.kernel.io` vs `tudatpy.io` - `tudatpy.io` will point to `tudatpy.io`, and not `tudatpy.kernel.io` - This applies to **objects**, **not their children**, so all children of `tudatpy.kernel.io` will become available under `tudatpy.io`, unless `tudatpy.io` already has objects with the same name: - `tudatpy.kernel.io.abc`: will become available through `tudatpy.io` as `tudatpy.io.abc` - `tudatpy.kernel.io.abc`, **but** an object `tudatpy.io.abc` is defined in the Python `tudatpy.io` module: `tudatpy.io.abc` will point to the Python object. `tudatpy.kernel.io.abc` is not exposed from `tudatpy.io`
…at-team/tudatpy into feature/lean_kernel_exposure
Kernel exposure now done with import hooksFunctionality:
Characteristics:
BackgroundExposure is implemented through an import hook. An import hook is composed of:
Tale of an import
Once a package specification has been created, the following takes place:
Complete pseudocode
Implementation
MechanicsThe entire process takes place through
|
@alopezrivera, I think the same modification will need to be made for other 'hybrid' modules as well (right not, it's only in gravity_field, right?). Is there a way to automate this to prevent issues with other (and future) hybrid modules? |
Assuming you refer to 48fe01c, the change is cosmetic and everything would work even if we kept the explicit import of kernel objects. I removed it because the exposure makes that import unnecessary. More generally, the only requirement for tudatpy Python code is that tudatpy subpackages (aka folders under tudatpy that contain .py files, such as |
…imulation.propagation
Closing, since all this is now part of #159 |
Copy of #152, which was undone due to failures on Azure
This PR simplifies the tudat kernel exposure in tudatpy:
Exposure
Explicit kernel exposure with Python wrappers deprecated in favor of exposure by modifying sys.path after importing the compiled tudatpy.kernel module
Autocompletions
Achieved by the use of stubs, generated at compile-time using mypy.stubgen