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

[Jimmie Houchin]

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 and also the DLL Assembly References 
I've added to access the libraries my app requires.

Unfortunately, for most of what I would like, I believe it would require 
WingIDE to support the use of IronPython. Is this accurate? And if 
WingIDE did support the use of IronPython would it make what you are 
doing easier or possibly unnecessary?

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
> 
>