[Zope] external methods and pyc files

[Richard Jolly]

Paul Winkler wrote:

> On Fri, Feb 06, 2004 at 04:18:56PM +0000, Richard Jolly wrote:
> 
>>If the .py files are in the Extensions folder, then this works fine. If, 
>>however, only the .pyc files are in, then I get the same behaviour as 
>>before. It appears that the wrong method is called - however perhaps the 
>>right method (by name) is called, but the wrong code is associated with 
>>it, because it can't be loaded from the .pyc file or some such. Can the 
>>reload be silently failing for a pyc file?
> 
> 
> Are you sure those .pyc files are correct?
> I believe Zope doesn't normally write .pyc files for external methods.

I did check. The .pyc files were compiled elsewhere and put in place as 
a 'security' measure, or something like that. (Which caused an earlier 
part of my confusion because the zope errors would report file paths 
that I knew did not exist on the system. They turned out to be the 
location at which the .pyc files were created.)

>>These errors are triggered by the call to the second external method 
>>sharing the same function name that is called. It doesn't matter which 
>>is called first, but when the second is called, it fails and will 
>>consistently fail from then on.
>>
>>There is another wrinkle.
>>
>>There are two identically named functions in the .py files. One of these 
>>is unused.
>>
>>Root
>> A/
>>   methx_strange
>>     id = methx_strange
>>     module = foo.py
>>     name = strange
>>  B/
>>   other external methods
>>
>>foo.py
>>  def strange
>>
>>bar.py
>>  def strange
>>
>>On occaision bar.py's strange method is called. How can this be?
>>
>>I'm at a loss to explain this unless somehow the module name is not used.
> 
> 
> Fortunately, that is not possible :-)

Thats good news - one less problem to think about ;-)

>>I'm sure I don't understand half as much as I should. Is there an easy 
>>way to get all information about the context/caller of an external method?
> 
> 
> You could have the ext. method return str(REQUEST) as part of its output.
> Maybe also self.getPhysicalPath() which should tell you something
> about the calling context.

This was very helpful - although didn't acutally enlighten me.

>>Info I should have mentioned earlier:
>>	
>>Zope Version Zope 2.3.2 (binary release, python 1.5.2, win32-x86)
> 
> 
> You do realize that's three years old, right?
> It is certainly possible that this is an old long-solved
> bug, but I have no knowledge of that.

I know, I know. Unfortunately I don't have any control over this. I did 
find a bug report that may be related. It was rejected as not being a 
bug - kind of like my situation :)

http://zope.org/Collectors/Zope/29

Anyway, the solution I've come to is to import new .zexp files with the 
external method names changed to prevent conflicts, and put the .py 
files in place to be sure the external methods load.

If I had time and a little more Zope patience I'd attempt to create a 
test case to see if there really was a problem  besides a lack of 
understanding of aquisition. Luckily for me this chapter is considered 
closed, and I can return to work about which, hopefully, I am not so 
clueless.

Thanks very much for you help,

-- 
Richard Jolly