Cant declare classes in Scripts with 2.7 and Python 2.3

[Chris McDonough]

Jamie Heilman reports:

In 2.3 you can no longer declare new classes in a Script object. It
> bitches about a lack of __name__ attribute. I haven't really had the
> time to look into it closely, but it does effect the examples shipped
> with zope, and actually its just a very useful thing to be able to do.
> Whatever this problem stems from, there will probably be more because
> of it.

[Tim Peters (tim-one)]

On zope-dev, Fred L. Drake, Jr. said:

"""
In Python 2.3.x, when a class is defined the __name__ of the
encompassing module is looked up. I suspect Python Scripts can be
fixed by defining __name__ in the globals dictionary in which the code is executed.
"""

[Jamie Heilman (jamie-audible)]

Yeah, defining it does fix the bug for script objects, but what
should __name__ in the globals dict be defined as?

[Evan Simpson (evan-4-am)]

Status: Pending => Resolved

Fixed in HEAD and 2.7 branch.

[Evan Simpson (evan-4-am)]

Status: Resolved => Accepted

 Supporters added: evan

Setting __name__ to the Id of the Script, my original "fix", fails if the Id contains a period ('.'). This causes wacky import problems, which leads to hair-tearingly opaque security problems.

Solution #1: Omit or replace periods in the __name__

Solution #2: Set the __name__ to None

Solution #Inf: Get this fixed in Python 2.3.4

I actually like #2 the best, since it is immune to weird Script names and produces class repr's that look like "<class ?.foo at 0x41696bfc>"

[Evan Simpson (evan-4-am)]

It looks probable that Zope 2.7 final will have __name__ set to None. This introduces one known problem, where a DeprecationWarning triggered by a Script is converted into an unrelated exception. I have code in a sandbox that fixes this (by setting __file__), but this is a small enough issue that I won't check it in until after the final release.

[Jamie Heilman (jamie-audible)]

So ... you added:

    get_filepath=None # Public
    def get_filepath(self):
        return self.meta_type + ':' + '/'.join(self.getPhysicalPath())

Um. get_filepath=None ? I'm not sure why this method even needs to be public, but if you really want it to be so, perhaps using declarative security is a good plan.

[Tres Seaver (tseaver)]

Hmm, that assignment is by definition meaning free: the 'def' statement immediately following it overwrites the
binding of 'None' to the name "get_filepath"!

WRT the intent: 'get_filepath' should probably be
protected with the same permission ("View management
screens") which guards the other "accessor" methods (e.g.,
'body', 'params', 'document_src', etc.

We should also look at breaking up the monolithic
permission declarations, bringing them in line with the
style used by the rest of Zope (permission declarations
immediately prior to the actual method).

[Jamie Heilman (jamie-audible)]

> Hmm, that assignment is by definition meaning free: the 'def' statement
> immediately following it overwrites the
> binding of 'None' to the name "get_filepath"!

There's no logical reason to do that though is there? (I see you removed it from the source, so I assume there isn't but...) Seeing that kind of thing makes me start to question my python-fu and wonder if theres more going on within the class than I thought. Anywho, I agree, declarative security is really a good idea, and infact I already converted this file, lets see if I can jimmy up a patch.

[Jamie Heilman (jamie-audible)]

http://marc.theaimsgroup.com/?l=zope-dev&m=108344868518765&w=2

[Jamie Heilman (jamie-audible)]

errr, ok so my patch declares get_filepath public, I guess you should change that to whatever you want to protect it as. Seems to me it could be private, but protected with the management perm works too.

[Tim Peters (tim-one)]

Uploaded: psdsec.diff

Just attaching Jamie's patch (psdsec.diff).

[Tres Seaver (tseaver)]

Fix released long ago.