Home » Support » Index of All Documentation » Wing IDE Reference Manual » Source Code Analysis »

13.2. Helping Wing Analyze Code

There are a number of ways of assistant Wing's static source analyzer in determining the type of values in Python code.

Using isinstance() to Assist Analysis

One way to inform the code analysis facility of the type of a variable is to add an isinstance call in your code. An example is assert isinstance(obj, CMyClass). The code analyzer will pick up on these and present more complete information for the asserted values.

In cases where doing this introduces a circular import, you can use a conditional to allow Wing's static analyser to process the code without causing problems when it is executed:

if 0:
  import othermodule
  assert isinstance(myvariable, othermodule.COtherClass)

In most code, a few such assertions go a long way. The more Wing knows about your code, the faster you will be able to edit and navigate it.

Using *.pi files to Assist Analysis

Wing's source analyser can only read Python code and does not contain support for understanding C/C++ extension module code other than by attempting to import the extension module and introspecting its contents (which yields only a limited amount of information and cannot determine argument number, name, or types).

To inform the code analysis facility of the contents of an extension module, it is possible to create a *.pi (Python interface) file. For example, for a module imported as mymodule, the interface file is called mymodule.pi. This file is simply a Python skeleton with the appropriate structure and call signature to match the functions, attributes, classes, and methods defined in an extension module. In many cases, these files can be auto-generated from interface files.

Wing will search for *.pi files first in the same directory as it finds the extension module (or its source code if it has not yet been compiled and the source code's directory is on your configured Python Path), If not found, Wing will look in the directory path set with the Interfaces Path preference. Next, Wing will look in the resources/builtin-pi-files directory within your Wing IDE installation. Finally, Wing will look in resources/packages-pi-files, which is used to ship some *.pi files for commonly used third party packages.

When searching on the interfaces path or in the resources directories, the top level of the directory is checked first for a matching *.pi file. Then, Wing tries looking in a sub-directory #.# named according to the major and minor version of Python being used with your source base, and subsequently in each lower major/minor version back to 2.0.

For example, if c:\share\pi\pi-files is on the interfaces path and Python 2.3 is being used, Wing will check first in c:\share\pi\pi-files, then in c:\share\pi\pi-files\2.3. then in c:\share\pi\pi-files\2.2, and so forth.

Example *.pi files used by Wing internally to produce autocompletion information for builtins can be seen in the directory resources/builtin-pi-files inside your Wing IDE installation. This also illustrates the above-described version number fallback mechanism.

In cases where Wing cannot find a *.pi at all, it will attempt to load the module by name (in a separate process space) so that it can introspect its contents. The results of this operation are stored in pi-cache within the User Settings Directory and used subsequently. This file is regenerated only if the *.pyd or *.so for the loaded module changes.