[Zope-dev] uuid.UUID as a rock in zope.security

[Martijn Faassen]

Hey,

Jim Fulton wrote:
[snip]
> I don't see the point of a separate package. This is a very small  
> corner of zope.security.

Sure, it could be solved within zope.security as well.

> A simple API for extending the definition of rocks would be enough to  
> deal with this particular issue.
> 
> Note that "considered immutable" is rather vague.  UUIDs aren't  
> immutable if you're willing to be only slightly devious.  But if you  
> aren't worried about that in an application, then that isn't a  
> problem.  You might even choose to make truly mutable objects into  
> rocks if you know your application is going to play nice.

Right, I meant "considered immutable" in the dynamically typed sense. I 
can make classes that I consider to be immutable after creation in 
Python, even though I don't actually enforce it by preventing people 
from setting attributes on them.

>> People trying to port zope.security dependent code to the google app
>> engine seem to have yet another use case. This is fulfilled right  
>> now by
>> a hacked up fork that at least makes import works, even though none of
>> the actual functionality is there. We might want to put a knob in
>> zope.security to support this hack out of the box too.
> 
> Or tell them to use something else altogether.  It all depends on  
> their use cases.  If they want a seatbelt rather than a space suit, I  
> suppose a python-based proxy could be good enough, although it would  
> likely be too slow for that environment.

The use case appears to be to use code that depends on zope.security on 
the google app engine. We have quite few libraries that do that out 
there. I think they just simply hack the proxy creation out completely, 
meaning that zope.security is basically a no-op. I asked what exactly is 
going on in another thread, so we just wait until we find out. :)

Regards,

Martijn