launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 26 July 2010 17:28:01 Aaron Bentley wrote:
> On 07/26/2010 12:13 PM, Julian Edwards wrote:
> > On Monday 26 July 2010 16:24:33 Aaron Bentley wrote:
> >> On 07/26/2010 11:10 AM, Julian Edwards wrote:
> >>> On Monday 26 July 2010 16:01:31 Jonathan Lange wrote:
> >>>>> I guess I'm struggling to see how @classmethod is useful then.  In
> >>>>> fact, it's dangerous.
> >>>> 
> >>>> Why do you think it's dangerous?
> >>> 
> >>> Because it allows someone to get hold of a new object that is not
> >>> security wrapped.
> >> 
> >> So does FooSet.new.  What's the difference?
> > 
> > None - that's exactly what I was referring to.
> 
> So this means that FooSet.new is also dangerous.  So why do you say that
> a @classmethod is dangerous, if it's no more dangerous than a normal
> method?

Argh, sorry I misread your last email.

If there's no @classmethod on new() then you need an instantiated object.  At 
that point, it's more likely that you've DTRT regarding <securedutility> 
rather than circumventing the proxy by calling the classmethod.

So, if I understand this stuff right, you simply don't need the @classmethod 
if you call getUtility(IFoo).new()

> >>>  I don't know why you'd ever want to do that.
> >> 
> >> It's very convenient in test code.
> > 
> > Why?  Why do you need to ignore security?
> 
> Because I want to set up preconditions for my test that are much easier
> to do by poking at internal state than by using the approved Interface.
>  Because it's sometimes easier or more precise to verify postconditions
> by looking at internal state than by using the approved Interface.
> 
> > If it is *really* needed, I would *much* rather see an explicit
> > removeSecurityProxy() with a comment explaining why you need to remove
> > the wrapper.
> 
> Sure, explicitly removing the security proxy is clearer.  I don't agree
> about the need for a comment.

Maybe I am jaded by bad Soyuz code, but I've seen removeSecurityProxy used all 
over the place because someone didn't understand the security.  I therefore 
feel aggrieved when I see one, and demand a comment to explain it. :)

> >> def FooSet.destroyFoo(self, foo) <- We can't check whether the user has
> >> permission to delete this object at the zope level, because it's foo,
> >> not self.
> > 
> > I agree with all of this, except that I can't say I've ever been
> > encouraged to have a delete method on a utility :)
> 
> Having seen a delete method on a utility, I can only assume some people
> have been.

That's, umm, interesting.  In a bad way. :(

> > But still, we can do store.remove() anywhere and that's not checked.
> 
> Indeed.  It's not about making evil impossible, it's about helping
> ourselves to avoid mistakes.

Totally.  That's why I'm advocating getting rid of @classmethod on that new() 
:)