Not logged in▾
Log In Register
Forgot Password Resend Validation E-mail

How to expose custom .NET application types to Python IntelliSense in SyntaxEditor Python Language A

SyntaxEditor Python Language Add-on for WPF Forum

The latest build of this product (v26.1.0) was released 29 days ago, which was before this thread was created.
Posted 9 days ago by Jakub M - R&D Engineer, Hitachi Energy
Version: 26.1.0
Avatar

Hello,

We are developing a WPF desktop application that allows users to create and execute both C# and Python scripts.

For C# scripting, we expose our application's .NET types to the scripting environment and IntelliSense works very well. Users can see our custom classes, methods, properties, and type information directly within the editor.

We are now adding support for Python scripting using the SyntaxEditor Python Language Add-on and would like to provide a similar experience.

Our Python scripts are executed through Python.NET, which allows Python code to access our .NET assemblies and types at runtime. While the scripts execute correctly, IntelliSense in the SyntaxEditor does not recognize our application-specific .NET types.

For example, assume we expose a .NET type like:
public class DeviceManager {
public string Name { get; set; }
 
public void Connect() { }
}​

and make it available to Python scripts. We would like users to get IntelliSense for scenarios such as:

from MyApplication import DeviceManager
 
device = DeviceManager()
device.

where IntelliSense would show:

  • Connect()
  • Name
  • documentation/tooltips
  • method signatures

Questions:

  1. Does the Python Language Add-on support exposing custom .NET types for IntelliSense?
  2. Is there a recommended approach for integrating Python.NET types with the resolver/introspection system?
  3. Are there any samples demonstrating how to add custom symbols, modules, or type providers to the Python language service?
  4. If this is not supported out of the box, what would be the recommended extension point for implementing custom IntelliSense backed by our application's .NET type system?

Our goal is to provide Python users with an IntelliSense experience similar to what they receive when authoring C# scripts in our application.

Any guidance, examples, or best practices would be greatly appreciated.

Thank you!

Comments (4)

Answer - Posted 9 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Jakub,

The Python Language Add-on does not automatically discover .NET types exposed through Python.NET. Its IntelliPrompt resolver analyzes Python .py modules in the Python project's search paths only.

What you could do is create some stub .py files in a private search path that only contain the headers for your public .NET API without any of the implementation details. The stub .py files can have code like:

class DeviceManager:
    """A device manager."""
    
    @property
    def Name(self):
        """Gets the name"""
        return ""
    
    def Connect(self):
        """Connects to a device."""
        pass

All they need is member names (the "Connect") and a standard return type constant, None for complex objects, or "pass" for void returns.

You can use normal Python docstrings to add documentation comments in the .py files. 

That's effectively what we do for the part of the Python standard library that is defined in C++ that has no .py source. We built up stub .py files that mimic what a .py would look like and allow our default .py file parser to load it all up into reflection, which drives the IntelliPrompt features.

We don't have any samples of this at this time, but it's effectively just saving .py files in a folder that is referenced in the Python project's search paths.

As a last resort, the PythonCompletionProvider also has an OnSessionOpening method you can override if you like and add/change/remove completion items before the list shows. You could do that kind of thing if the suggestion above doesn't work, but it would be better overall to try something like above.

I hope that helps.

Actipro Software Support

Posted 9 days ago by Jakub M - R&D Engineer, Hitachi Energy
Avatar

Thank you for the explanation regarding the Python language service and .py stubs.

We have an additional question regarding our use case.

Our application supports both C# and Python scripting. For C# scripting, we already have a fully configured FileBasedAssemblyRepository, and IntelliPrompt is able to provide completion, signatures, documentation, and type information for our application's .NET types.

Since the same .NET types are available to both scripting environments, we were wondering whether there is any supported or unsupported ("hacky") approach to reusing the existing .NET IntelliPrompt infrastructure from within Python editing.

For example:

  • Could a custom Python resolver somehow delegate symbol resolution to the .NET type repository?
  • Is it possible to leverage the IntelliPrompt data from a hidden .NET editor/document and surface those completion results in a Python editor?
  • Have you seen customers implement a hybrid solution where Python completion is backed by information coming from the .NET language service rather than Python introspection alone?

We realize this may be outside the intended architecture of the Python add-on, but before investing in a fully custom solution, we wanted to understand whether there is any practical way to reuse the rich metadata already available through our .NET scripting setup.

Any guidance or recommendations would be greatly appreciated.

Posted 8 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Jakub,

There is no public API for the Python add-on to delegate symbol resolution to the .NET add-on's FileBasedAssemblyRepository. They use separate resolver implementations and internal models. A hidden C# editor would still require custom code to translate Python context and present the resulting symbols in Python IntelliPrompt, so we do not have a hybrid approach or sample to recommend. PythonCompletionProvider.OnSessionOpening can modify an existing completion list, but it does not provide that resolver bridge.

For now, generating .py stubs from your .NET type metadata is the most practical route. If you have Blueprint source code for the relevant add-ons, you could explore a tighter integration by changing their internals, though you would need to maintain those changes.

We've made notes of your use case as a suggestion for possible symbol-resolution extension points if we refactor the Python add-on down the road.

Actipro Software Support

Posted 8 days ago by Jakub M - R&D Engineer, Hitachi Energy
Avatar

Hi,

Thank you for the detailed explanation. Having extension points that would allow custom symbol resolution or integration with external type systems would be very valuable for applications like ours that support multiple scripting languages on top of the same .NET object model.

We appreciate the guidance and will proceed with investigating stub generation.

Thanks again for your help!

Add Comment

Please log in to a validated account to post comments.