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.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list