[wingide-users] Re: Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)

Michael Foord fuzzyman at voidspace.org.uk
Thu Apr 30 05:07:07 MDT 2009

Jimmie Houchin wrote:
> This sounds great. I am new to both IronPython, WingIDE and Windows 
> development in general.
> One of the disappointing things with WingIDE for me is the total 
> absence of autocompletion of .NET imports 

Which is what my script provides. The autocomplete for .NET now in Wing 
is pretty awesome. Once I've added method return type hints it will be 
even better.

> and also the DLL Assembly References I've added to access the 
> libraries my app requires.

What do you mean by this?

The *correct* way to do this with IronPython is by calling 
clr.AddReference yourself.

> Unfortunately, for most of what I would like, I believe it would 
> require WingIDE to support the use of IronPython. Is this accurate? 

What do you mean by 'for most of what I would like'? Anything in 
addition to the two points above?

> And if WingIDE did support the use of IronPython would it make what 
> you are doing easier or possibly unnecessary?

The PI file mechanism is how Wing provides autocomplete - I've just made 
it work for .NET types, so this *is* Wing supporting IronPython. You can 
use Wing scripting to integrate other tools into Wing - see the example 
script I provided for running the current file with IronPython.

You might also want to integrate the IronPython debugger that Harry 
Pierson has been working on:


The other possibilities are:

* Integrated IronPython shell - the Wing team are reluctant to do this 
unless they can port the *whole* debugger across. Shame. ;-)
* The debugger - impossible at the moment because of limitations in 
IronPython, which may be addressed in IronPython 2.6 (where we also get 
profiler support). After that it is still a lot of work and so I'm not 
massively hopeful of seeing it in Wing any time soon.
* Test support - Wing has great integrated testing support. It would be 
nice to see that work with IronPython. (It may do if you set IronPython 
as the project interpreter - but as that breaks the shell I don't do it 
and integrate testing myself through the Wing scripting API.)


Michael Foord

> I am exploring my IDE options. So I am somewhat disappointed with 
> WingIDE not providing autocompletion or any of the features for which 
> I am explicitly needing to use IronPython for. Unfortunately I really 
> haven't found anything that does provide autocompletion for the 
> libraries I've imported via clr. Oh well. It is possible I've missed 
> something.
> I would love to see WingIDE support IronPython and enabling 
> autocompletion, debugging, etc. on .NET and clr imported libraries and 
> modules.
> Thanks for doing this Michael. It will be a nice help. And also thanks 
> for your book which I am working my way through.
> Jimmie Houchin
> Michael Foord wrote:
>> Hello all,
>> Attached is an updated script for generating PI files to provide 
>> autocomplete on standard .NET objects.
>> It now handles all the standard .NET member types (including static 
>> properties, enumeration fields, indexers, events and so on).
>> It also recurses into sub-namespaces generating new pi-files for all 
>> of them.
>> This script is hardcoded to add references to, and then generate PI 
>> files for:
>>    System
>>    System.Data
>>    System.Drawing
>>    System.Windows.Forms
>> It generates 90 pi files (90 namespaces) taking up 24mb! The 
>> autocomplete it provides is awesome though. :-)
>> I had to do a fair bit of violence to the standard generate_pi.py 
>> script so I *doubt* it is desirable to merge it back in. Obviously 
>> very happy for this to be included with Wing if you want, or merged 
>> if you think it is worth it. Is it ok for me to offer this for 
>> download from my site? If I make further changes I will email this list.
>> The big thing to add is the return type for methods.
>> Is it possible to specify return types for properties? (Currently any 
>> attribute without an obvious parallel in Python I have turned into a 
>> property in the PI files).
>> The only real caveat with the current script (that I am aware of - 
>> bug reports and contributions welcomed) is that None is a common 
>> enumeration field member. This is invalid syntax in Python, so I 
>> rename these to None_.
>> There are quite a few minor changes sprinkled through the code - plus 
>> the __main__ part of the script is very different. I have tried to 
>> mark changes with a # CHANGE: comment, but it should be relatively 
>> amenable to diffing anyway...
>> For reference I was using IronPython 2.0.1, with .NET 3.5 installed 
>> and Wing 3.2beta 1.
>> All the best,
>> Michael Foord
>> Michael Foord wrote:
>>> Hello all,
>>> I've created a modified version of the 'generate_pi.py' which 
>>> generates the interface files for .NET libraries. It is attached.
>>> At the moment it generates PI files for the following assemblies / 
>>> namespaces (hardwired at the bottom of the code):
>>>    System
>>>    System.Data
>>>    System.Drawing
>>>    System.Windows.Forms
>>> To run it, create a new directory and add this to the 'Interface 
>>> File Path' (File menu -> Preferences -> Source Analysis -> Advanced 
>>> -> Insert).
>>> Then from the command line switch to this directory (if you are on 
>>> Vista you will need to run cmd with admin privileges due to a defect 
>>> explained below). Execute the command:
>>>    ipy generate_pi_for_net.py
>>> This generates the pi files. It doesn't work *as well* on 64 bit 
>>> windows because the .NET XML help files (or whatever they are 
>>> called) are in a different location so the docstrings are not always 
>>> available - which is why I am not just distributing the pi files yet.
>>> The script doesn't yet understand static properties on classes - so 
>>> it actually *fetches* static properties rather than looking at the 
>>> descriptor (which is available in the class __dict__ so should be 
>>> easy to fix). This is what causes inadvertent registry lookups etc 
>>> and therefore requires admin privileges.
>>> It doesn't yet understand multiple overloads. This may require a 
>>> change to Wing or may not matter.
>>> It isn't yet able to do anything with the information about return 
>>> types - which would allow Wing to know the type of objects returned 
>>> by methods. This may be easy to add?
>>> It is late so I am going to bed. At some point I will explain the 
>>> simple changes I  had to make to the standard generate_pi.py script 
>>> (although they are mostly straightforward). I will also do further 
>>> work on it as it will be very useful to me...
>>> All the best,
>>> Michael
>>> ------------------------------------------------------------------------ 
>>> _________________________________________________
>>> Wing IDE users list
>>> http://wingware.com/lists/wingide
> _________________________________________________
> Wing IDE users list
> http://wingware.com/lists/wingide


More information about the wingide-users mailing list