You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First I want to express my thanks for pythonstubs. It it has the potential to help our org better maintain our legacy rhinopython code. Second, I would like to express a problem we're having, and propose a solution.
In our rhino python code, we like to explicitly import static functions from Rhino classes when possible, to help telegraph the intention of an import:
fromRhino.Geometry.RtreeimportCreatePointCloudTree# I bet we'll create a point cloud tree later 🤔
{...}
CreatePointCloudTree(some_points) # How did we know that?! 🤯
However, the current stub setup will fail to recognize these sorts of imports (for example in pycharm):
The crux is that RhinoPython lets us import a .net class as if it were a python module. However, the current stub layout - one .pyi per major rhino namespace - can't recognize these "class module" style imports.
To resolve the issue in the most literal way, we could represent the additional class modules as .pyi stubs. These stubs would correctly recognize the import examples I've shown:
Pystubbler would dump these "class modules" using the same method it uses to dump namespace modules. This would make the stubs significantly more faithful to the true article, and more fit to our organization's needs.
Feedback would be welcome. This capability would be useful for our organization; if a particular solution design gets maintainer endorsement, I would like to sponsor and submit the fix.
The text was updated successfully, but these errors were encountered:
First I want to express my thanks for pythonstubs. It it has the potential to help our org better maintain our legacy rhinopython code. Second, I would like to express a problem we're having, and propose a solution.
In our rhino python code, we like to explicitly import static functions from Rhino classes when possible, to help telegraph the intention of an import:
However, the current stub setup will fail to recognize these sorts of imports (for example in pycharm):
The crux is that RhinoPython lets us import a .net class as if it were a python module. However, the current stub layout - one .pyi per major rhino namespace - can't recognize these "class module" style imports.
To resolve the issue in the most literal way, we could represent the additional class modules as .pyi stubs. These stubs would correctly recognize the import examples I've shown:
Pystubbler would dump these "class modules" using the same method it uses to dump namespace modules. This would make the stubs significantly more faithful to the true article, and more fit to our organization's needs.
Feedback would be welcome. This capability would be useful for our organization; if a particular solution design gets maintainer endorsement, I would like to sponsor and submit the fix.
The text was updated successfully, but these errors were encountered: