Skip to content
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

Provide a python type interface (.pyi) module for the python client interface #508

Open
analog-cbarber opened this issue Oct 3, 2024 · 2 comments

Comments

@analog-cbarber
Copy link

The Python_sml_ClientInterface module generated by SWIG provides C++ style function declarations in the
generated comments but does not declare Python type signatures. As a result, features that depend on Python
declarations will not work. This includes type checking from lint tools like mypy or pyright as well as autocompletion
features from various IDEs that support Python.

One workaround for this is to provide a parallel Python_sml_ClientInterface.pyi file that provides cleaned up
doc strings and type signatures. This will be used by the IDE and type checking tools but will not affect the actual
runtime behavior. You could simply copy the generated SWIG interface file, delete the runtime code, tweak
the docstrings to be more python-friendly, and adding type signatures.

For instance, the generated CreateAgent method is:

    def CreateAgent(self, pAgentName):
        r"""
        CreateAgent(Kernel self, char const * pAgentName) -> Agent

        Parameters
        ----------
        pAgentName: char const *

        """
        return _Python_sml_ClientInterface.Kernel_CreateAgent(self, pAgentName)

this could be changed to something like:

    def CreateAgent(self, name: str, /) -> str:
        r"""
        Args:
            name: name for agent
        """

Note: the point of the / is to disable use of keyword argument invocation in the declaration since
this changes the name of the argument name from the actual declaration. If we think that users will
want to use keyword argument invocations, then we can keep the existing name (even though the
names will be awkward in Python).

Obviously, such a file would have to be updated if/when the generated SWIG interface changes, but it would definitely help productivity for any Python SML users.

Also note, that an interface file like this could actually be provided by a standalone Python package and does not necessarily need to be part of the main release.

@garfieldnate
Copy link
Collaborator

Not having typing is one of my major gripes with SWIG. A type stubs file would be a nice fix! The one drawback being, of course, that it will be easy to accidentally let it go out of date.
I think Copilot could probably generate a lot of the file, as well.

@analog-cbarber
Copy link
Author

I don't think I would trust Copilot that much. It all too often gets things wrong, but ok if you make sure to check everything it produces.

It probably would make sense to wrap the entire SWIG interface with one that has an easier to use in Python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants