[IronPython] Pywin32 porting woes...

Lukas Cenovsky cenovsky at bakalari.cz
Wed May 12 21:29:48 CEST 2010


Trying to work with CPython win32api is not a good idea. You should use 
win32 api directly via clrtype.py and pinvokes. Download (Sample) 
ClrType.zip 
<http://ironpython.codeplex.com/releases/view/36280#DownloadId=116513> 
from http://ironpython.codeplex.com/releases/view/36280 and check how 
for example MessageBox function is imported from user32.dll. The same 
way use for all functions you need from win32 api (replace pywin32 
module with your proxy module).

--
-- Lukás(


Will Sadkin wrote:
> Hi list,
>
> I am not sure who to go to with this... 
>
> We have a large legacy CPython library set that makes extensive use of
> the pywin32 extensions Mark Hammond wrote.  I would like to use
> IronPython to build a RESTful service around the use of this code, but
> have discovered that this will be problematic at best, and impossible at
> worst.
>
> I saw through some net searching that William Reade managed to get some
> portions of win32api to work last year using ironclad
> (http://www.mail-archive.com/users@lists.ironpython.com/msg08921.html)
>
> So I thought I'd try to see how far I could get with some of the win32
> stuff...  I managed to get win32api to import with a zillion warnings,
> but when I tried to import pythoncom, I got errors nesting down to a
> problem with the import of pywintypes.
>
> Looking into the code, it assumes that sys.platform startswith("win32")
> must be True if it's windows; this isn't the case with ipy; instead it's
> "cli".  
>
> Ok, easy to modify, to get to the next issue in the onion, which I'm
> stumped on...
>
> 'import pythoncom' fails.  I've worked through the code enough to track
> down the source of this to problems importing from the pywintypes dll.
>
> It turns out that in cpython:
> C:\> c:\Python26\python.exe
> Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
> (Intel)] on
> win32
>   
>>>> import imp
>>>> imp.load_dynamic('pywintypes',
>>>>         
> r'C:\Windows\system32\pywintypes26.dll')
> <module 'pywintypes' from 'C:\Windows\system32\pywintypes26.dll'>
>
> That is, imp.load_dynamic() returns a module object for this.
>
> In ipy :
> C:\> C:\Program Files (x86)\IronPython 2.6\ipy.exe
> IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4062
>   
>>>> import sys
>>>> sys.path.append(r'c:\ironclad-v2.6.0rc1-bin')
>>>> import ironclad
>>>> import imp
>>>> imp.load_dynamic('pywintypes',
>>>>         
> r'C:\Windows\system32\pywintypes26.dll')
>   
>
> That is, in ipy, the imp.load_dynamic() *doesn't* return a module, and
> raises no exception or anything that would indicate why this was the
> case.
>  
> Which leads to the following questions:
> 1) Can anyone tell me why this is?  
> 2) Is this an ironclad issue, an ipy bug, an incompatible change in
> imp's behavior in ipy, or something else?  
> 3) Is this a path worth pursuing?  
> 4) If not, can anyone give me any recommendations for what to use
> instead of ipy?
> 5) Also, as an aside, will ironpython ever support .pth files to augment
> the module search path?
>
> Thanks,
> /Will Sadkin
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100512/9bf151cc/attachment.html>


More information about the Ironpython-users mailing list