On Thursday 25 August 2005 23:50, Gary Poster wrote: > Jim mentioned to me a while ago that he was planning to have security > settings for classes inherit. I was against it, because I thought > that like_class answered the use case sufficiently, explicitly, and > not overly annoyingly. > > However, in order to get pytz timezones--a large set of automatically > generated classes that potentially change every quarter--to do what > we want without that, I only see monkeypatches. :-/ So I'm +1 on > inherited security I guess.
I am +1, *if* it can be overwritten, which I think it would. On the other hand, this change would need to be extremely well documented. For example, imagine we give BTreeContainer some permission for its method, then pretty much all our containers will have those permissions. Sometimes I specifically do not declare a permission because I never want a certain method to be accessed. This would mean we would have to explicitly be able to turn off a permission in a derived class. Of course, I could just create a permission that is never given to any principal, something like zope.noaccess, which would be the opposite to zope.public. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com