[Pythonmac-SIG] Python based apps woes on MacOs X (was :Re: [Pythoncard-users] Re: PythonCard on OS X 10.4 with Python 2.4.1)

[Alex Tweedly]

catonano at inwind.it wrote:

> Yes, Alex, you're right. It was a supposed bug when I opened the 
> thread, so the subject line was quite good at the moment.
>
>
>Later it became a bit obscure ;-)
>
>  
>
OK - as long as you didn't think anyone was doubting that it was a bug ....

>  
>
>>Something appears to have changed wrt the path that Python's sys.modules 
>>reports for imported files. 
>>    
>>
>
>  
>
>>As far as I know, no-one has yet verified 
>>for sure whether it is a Python bug or merely a platform-specific change 
>>that Pythoncard will need to adjust for. (Nor do I know how we'll be 
>>able to adjust - but I'm hoping that some of the PythonCard / Mac users 
>>are investigating ....)
>>    
>>
>
>That python user could be me !
>
>Alex, would you discuss a bit more about this Python issue ?
>
>  
>
Sure, I'll talk about it some, and maybe try to distill it down to a 
simple small program that would be easy to try out.
But first I'll give a few disclaimers.
 - I was totally unaware of this part of the code until this topic came up
 - I'm not a Python details kind of guy
 - I don't have, or have access to, a Mac

(So if Kevin has to come along and correct anything I say - don't be too 
surprised).

>sys.modules reportings about the imported files has changed ?
>Since when ?
>
>Does this affect the Apple installed python or the "third parties" ones ?
>  
>
No real idea since when. First guess would be between Python 
2.3.something and Python 2.4.something.

I have a vague idea that Apple installed python is 2.3, so it shouldn't 
be affected (but that's only a guess).

The issue is how PythonCard finds the resource files that go along with 
a Python source file. By default, they live in the same directory as the 
source file, and have an extra ".rsrc" appended to the base name (before 
the extension) - thus a source file xyz.py would have a resource file 
xyz.rsrc.py

PythonCard allows for various alternatives (language specific resource 
files, platform specific files, no file but an internal dictionary, 
etc.) and these make the code somewhat harder to follow. But if you 
ignore all those, the essence of what PythonCard does is

1. determine the full path name for the source file
2. modify it as above
3. read and eval() the resource file.

In this case, the source file is not the application itself, but an 
imported module. In the resourceEditor (in resourceEditor.py, in fact), 
we do

(before Kevin's suggested modification)
from modules.propertyEditor import PropertyEditor
....
        self.propertyEditorWindow = model.childWindow(self, PropertyEditor)

(or, after Kevin's suggested modification)
from modules import propertyEditor
....
        self.propertyEditorWindow = model.childWindow(self, 
propertyEditor.PropertyEditor)

(modules is a subdirectory within resourceEditor, propertyEditor.py is a 
source file, PropertyEditor is a class within that file).

So these two should be equivalent; Kevin suggested the change because 
this is the only place within PythonCard that this form of import is 
used - every other import is the second form (and there was some hope 
that this change would help).

I'll use the second version in this example below .... and probably get 
some of the terminology wrong.

When you call model.childWindow, you pass in the class you want - i.e. 
propertyEditor.PropertyEditor
childWindow() then derives the filename, splits off the extension, adds 
in the .rsrc.py and tries to read that file (remember I'm skipping over 
the internationalization part ...)

So it does  [ frameClass is the class wanted ]

                filename = sys.modules[frameClass.__module__].__file__
.....
            base, ext = os.path.splitext(filename)
            filename = internationalResourceName(base)
            rsrc = resource.ResourceFile(filename).getResource()


So - that's the background.

Brad sent the debug output from the first case above (before Kevin's 
suggested change), and also reported that the problem persisted after 
the change. So it looks likely that it's a Python bug. The Python docs 
are very sparse on what sys.modules should do.

I'd like to see a simple test output which is independent of PythonCard.

1. Create a test directory
     mine is called C:/python/projects/modulestest

2. create a subdirectory called "mmm"  (calling it "modules" was 
confusing me)

3. create a file within that subdirectory called   myFile.py   containing

> class myClass:
>     def init():
>         pass

4. create another tile in that subdirectory (to make it a package) 
called __init__.py containing

> # turn modules into a package

(note the name is underscore underscore i n i t underscore underscore . 
p y )

5. cd to the main test directory

> cd c:\python\projects\modulestest

6. run python, and do

> import sys
> from mmm import myFile
> myFile.myClass.__module__
> sys.modules[myFile.myClass.__module__].__file__

and see what the output is.

It *should* be the path name to the file ....
screen capture


This gives the same result on Python 2.4.1 on Windows.
I'd like to see the equivalent of this on each of Python 2.3 and 2.4 on Mac.

Then we'd know what the next step might be ... :-)

-- 
Alex Tweedly       http://www.tweedly.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050903/057ea05e/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen.PNG
Type: image/png
Size: 17272 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050903/057ea05e/screen-0001.png
-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: 31/08/2005