[IronPython] second attempt: problem with import, packages, and IronPython 1.1

Dino Viehland dinov at microsoft.com
Tue Feb 10 03:29:55 CET 2009


We fixed the case insensitivity issue in 2.0 so that might be incentive to upgrade :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
Sent: Monday, February 09, 2009 5:52 PM
To: Discussion of IronPython
Subject: Re: [IronPython] second attempt: problem with import, packages, and IronPython 1.1

Eureka - I'm an idiot.

Thanks for suggesting the simple trick of printing out the result of
dir(System).  I should have thought of that earlier.

Turns out the problem is that there is a module named system.py (all
lowercase) in the same subdirectory (or package) as the module I was
trying to import. I did not anticipate this behaviour, even on
Windows, as a Python 2.4 shell will happily import System.py and
system.py as different modules, provided they are in separate
directories of course.  That should be easy to fix, although there is
a lot of legacy CPython code depending on that unfortunately-named
'system.py' module.

So the IronPython behaviour appears to be different from CPython.  Is
that still true in 2.0?

Thank you very much for your help, and apologies for wasting your time.

pj

On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland <dinov at microsoft.com> wrote:
> If I setup this as you describe from the command line it just works:
>
> x\
>        subdir\
>                __init__.py
>                mymodule.py:
>                        import clr
>                        clr.AddReference('System')
>                        from System.Diagnostics import Process
>
>                        def foo():
>                        p = Process()
>                             return p
>
> C:\Product\2\Merlin\Main > "C:\Program Files\IronPython-1.1.2\ipy.exe"
> IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3521
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import sys
>>>> sys.path.append(r'C:/Product/2/Merlin/Main/x')
>>>> import subdir.mymodule
>>>> subdir.mymodule.foo()
> <System.Diagnostics.Process object at 0x000000000000002B [System.Diagnostics.Process]>
>
> The only thing I could think of is that clr.AddReference('System') is somehow picking up the wrong System.dll or System.exe.  You could try to run fuslogvw.exe and see what assemblies are getting picked up and where from, or you could just try changing the add reference to:
>
> clr.AddReference("System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL")
>
> which should always deterministically get the right assembly.  Alternately you could even try this from your hosting code:
>
> engine.LoadAssembly(typeof(System.Diagnostics.Process).Assembly);
>
> I don't remember whether we automatically loaded System.dll for you in 1.x or not so I don't know if that's necessary or not.  I'd also suggest doing a dir(System) to see what it prints out to see if there's a common theme amongst missing assemblies.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
> Sent: Monday, February 09, 2009 1:20 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] second attempt: problem with import, packages, and IronPython 1.1
>
> Hello IronPython team,
>
> This did not seem to hit home with anyone, but I thought I'd try
> again.  We'd like to avoid having to upgrade to IronPython 2.0 unless
> it's absolutely necessary.
>
> Hopefully someone can point me to documentation that can help me solve
> on my own?  I haven't been able to find anything relevant.
>
> Cheers,
>
> pj
>
> ============
>
> We embedded IronPython 1.1 in our application.  Unfortunately I am running
> into problems accessing .NET assemblies in Python.
>
> In one situation, if I create a module (let's call it mymodule.py) and put
> it in sys.path, with the following code in it:
>
> import clr
> clr.AddReference('System')
> from System.Diagnostics import Process
>
> def foo():
>     p = Process()
>     return p
>
> and then send the IronPython interpreter a script that imports mymodule and
> calls foo(), everything works fine:
>
> import mymodule
> p = mymodule.foo()
>
> However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
> which is in the search path as well and has an empty __init__.py file,
> thinks break:
>
> import subdir.mymodule
> p = subdir.mymodule.foo()
>
> I get: "ImportError: can't find module named Diagnostics".  It's as though
> the fact that I've "packaged" the module in a directory breaks the way
> IronPython gives me bindings to the .NET assemblies...  Why should this
> break?  Am I doing something wrong?
>
> Help!
>
> pj
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




More information about the Ironpython-users mailing list