[ZCM] [ZC] 1074/10 Comment "Cant declare classes in Scripts with 2.7 and Python 2.3"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1074 Update (Comment) "Cant declare classes in Scripts with 2.7 and Python 2.3"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1074

==============================================================
= Comment - Entry #10 by leper on May 1, 2004 5:59 pm

http://marc.theaimsgroup.com/?l=zope-dev&m=108344868518765&w=2
________________________________________
= Comment - Entry #9 by leper on May 1, 2004 5:26 pm

> 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.
________________________________________
= Comment - Entry #8 by tseaver on Mar 22, 2004 11:00 am

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).
________________________________________
= Comment - Entry #7 by leper on Mar 20, 2004 4:23 am

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.
________________________________________
= Comment - Entry #6 by evan on Feb 4, 2004 4:49 pm

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.
________________________________________
= Assign - Entry #5 by evan on Jan 6, 2004 4:46 pm

 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>"
________________________________________
= Resolve - Entry #4 by evan on Nov 4, 2003 2:46 pm

 Status: Pending => Resolved

Fixed in HEAD and 2.7 branch.
________________________________________
= Comment - Entry #3 by leper on Oct 7, 2003 11:00 pm

Yeah, defining it does fix the bug for script objects, but what 
should __name__ in the globals dict be defined as?
________________________________________
= Comment - Entry #2 by tim_one on Oct 6, 2003 10:03 am

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.
"""
________________________________________
= Request - Entry #1 by mcdonc on Oct 5, 2003 10:15 am

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.
==============================================================