[IronPython] [python] [IronPythonStudio] Namespace Classes andAssembly Files

Pigneri, Rocco rpigneri at LavaStorm.com
Wed Jan 30 18:25:30 CET 2008


Ah, ha!  I think I may have found the culprit!

If I have the following import sequences in the follwing order, then
only FormTwo is available:

from FormOne import *
from FormTwo import *

However, if they are in this order, then only FormOne is available:

from FormTwo import *
from FormOne import *

It seems that only the last class statement that is evaluated/imported
is retained.

Since I'm new to [Iron]+Python[Studio]+, I am unsure if this is correct
behavior that I have to be aware of or not.  Anyone else have any
insight?

Thank you,

Rocco

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Pigneri, Rocco
Sent: Wednesday, January 30, 2008 11:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] [IronPythonStudio] Namespace Classes
andAssembly Files

Here's the output from the project where FormTwo works:

['FormTwo', '__doc__', '__module__']

Here's the output from the project where FormOne works:

['FormOne', '__doc__', '__module__']

Really, this is quite fascinating.  There's no mention of the class that
was not run on the first time.  What's even more fascinating is that the
code files are identical, including the namespace classes (excluding, of
course, the class names and a few spaces after comments).

Rocco

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, January 29, 2008 7:03 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] [IronPythonStudio] Namespace Classes
and Assembly Files

Pigneri, Rocco wrote:
> Dear Michael,
>
> Well, I tried this out this morning, and I noticed that the plot has 
> thickened.  However, let me answer your question first:
>
>   
>>> I next add a new Form to the project by right-clicking on the 
>>> project
>>>       
>
>   
>>> name in the Solution Explorer, and go to Add->New Item->Windows
Form.
>>> I call this class FormTwo.  FormTwo is now placed in the Forms 
>>> namespace as well.
>>>  
>>> If I try to use the FormTwo class in the Program.py file (i.e. I
>>>       
> would
>   
>>> rather start up with FormTwo rather than FormOne), Forms.FormTwo() 
>>> does not do the trick.  The debugger keeps reporting that the class
>>>       
> is
>   
>>> not found.  This also happens if I add "from FormTwo import *" to 
>>> the
>>>       
>
>   
>>> top of the file.
>>>  
>>> What am I doing wrong here?  I feel like I should be able to
>>>       
> reference
>   
>>> any class in an assembly/project from any class in the same 
>>> assembly/project.  I have been able to get this to work by changing 
>>> the namespace class in FormTwo.py, but I feel like that is the wrong

>>> approach.
>>>       
>> Can you post the actual error you get? The import and reference you
>>     
> posted should work, so the exact error will tell us what is going
wrong.
>
> Here is the error message.  This is an exception that is thrown at 
> run-time.
>
> Title: MissingMemberException was unhandled by user code.
> Description: type object 'Forms' has no attribute 'FormTwo'
>
> Now, here's where the plot thickens: if I create the solution, change 
> the Program.py file to use FormTwo and then run the project *for the 
> first time*, it runs fine.  However, when I change the project to 
> FormOne and try to run it, it throws that exception.  The same happens

> in the opposite direction: if I run the program first with FormOne, 
> then it fails when I try it with FormTwo.  In other words, whichever 
> Form the Program.py file uses in its first run is the only one that it
can use.
> After that, it cannot find any other Form class.
>
>   

Wow that sounds like a tangled mess - but this is only Python after all,
so it should be following deterministic rules (I assume you are running
source code or are you running a compiled executable?).

How about throwing a 'print dir(Forms)' in their so you can see if your
form classes really exist.

Michael
http://www.manning.com/foord

> Thank you,
>
> Rocco
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Saturday, January 26, 2008 12:20 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] [IronPythonStudio] Namespace 
> Classes and Assembly Files
>
> Pigneri, Rocco wrote:
>   
>> Dear all,
>>  
>> I am new to Python, IronPython, and IronPythonStudio, but so far I am

>> enjoying the functionality that IPS offers me.
>>  
>> One thing that confuses me, however, is the namespace classes that 
>> IPS
>>     
>
>   
>> creates for me.  Let's say I create a Windows Forms project called 
>> Forms with a default form called FormOne.  FormOne is created in the 
>> Forms namespace while the Program.py file is placed in the Forms0 
>> namespace.
>>     
>
> This is annoying (unpythonic) but is probably due to the way the 
> CodeDom works - it basically creates the equivalent IronPython to the 
> C# it would generate.
>
>   
>>  
>> I next add a new Form to the project by right-clicking on the project

>> name in the Solution Explorer, and go to Add->New Item->Windows Form.
>> I call this class FormTwo.  FormTwo is now placed in the Forms 
>> namespace as well.
>>  
>> If I try to use the FormTwo class in the Program.py file (i.e. I 
>> would
>>     
>
>   
>> rather start up with FormTwo rather than FormOne), Forms.FormTwo() 
>> does not do the trick.  The debugger keeps reporting that the class 
>> is
>>     
>
>   
>> not found.  This also happens if I add "from FormTwo import *" to the

>> top of the file.
>>  
>> What am I doing wrong here?  I feel like I should be able to 
>> reference
>>     
>
>   
>> any class in an assembly/project from any class in the same 
>> assembly/project.  I have been able to get this to work by changing 
>> the namespace class in FormTwo.py, but I feel like that is the wrong 
>> approach.
>>     
>
> Can you post the actual error you get? The import and reference you 
> posted should work, so the exact error will tell us what is going
wrong.
>
> Michael Foord
> http://www.manning.com/foord
>
>   
>>  
>> Thank you,
>>  
>> Rocco
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> _______________________________________________
>> 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
>
>
>   

_______________________________________________
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