>Now - should methods of mutable types be off-limits in the
>future? [...] I don't think it would
>be acceptable for 'append' to be off-limits in this case, so
>the alternative is that the security machinery would somehow
>have to be able to distinguish mutables created by the user
>from those obtained from the secure environment. That would
>probably mean that API code would have to make some sort of
>security assertions about mutables they returned.
I have another alternative --
Unless I really intend to return an unprotected mutable across subsystems,
most often it's a mistake. Even if security isn't an issue, it leads to
wonderfully obscure bugs if a customer of my class blithely modifies my
return value. (I returned it to you, after all, you thought it was yours
now!) If I do want to return a dictionary for you to *read*, I could just
as easily code my intention and return a read-only class that implements
__getitem__.
Since on occasion I might deliberately want to return an unprotected
mutable value for a good reason, what would be helpful is if the security
system forbid me from returning unprotected mutable values unless I
explicitly say I intend to do so. I'd encourage the check to recursively
descend through tuples and, if we create a standard read-only dictionary
for everyone to use, through read-only dictionaries.
Note such a check would be just as helpful for products written using
Python Methods, or DTML, as it would be for products written in plain Python.
Then the security system doesn't need to keep track of where unprotected
mutables came from. Once I've said explicitly that I intend to return an
unprotected mutable, I can take care to return a copy that I don't use
after I've passed it on to you.
Andrew
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
