__no_side_effects__, was Re: [ZODB-Dev] Re: [Zodb-checkins] SVN: ZODB/branches/3.4/

[Tim Peters]

[blast from the past -- April 15]

[Tim Peters]
>> ...  I'd reserve intense dislike for, e.g., __no_side_effects__
>> (remember that one?).

[Paul Winkler]
> Yes, I found it recently when I fixed a bug in ZopeUndo/Prefix.py. Does
> anything actually rely on that attribute, and what for? The only check
> for it that I've found is in ZEO/zrpc/marshal.py, in find_global(), and
> it's not obvious why that function should rely on a double-underscore
> attribute.

I asked Jim about this yesterday, because it's been a mystery to me too.  I
thought I understood then, but looking again today I'm still missing
something.

It's generally true that ZEO should never try to instantiate a class while
unpickling network messages, because network messages are untrustworthy, and
there are ways to trick pickle into executing near-arbitrary code as a side
effect of unpickling.  So ZEO's lowest-level message decoding mechanism
(which you found in marshal.py) sets its unpickler's `find_global` function
to one that "almost always" just raises an exception.  That alone cuts off
most ways to trick an unpickler into doing bad things.

It doesn't raise an exception if the unpickler tries to load a class object
with a true `__no_side_effects__` attribute, and that is the only use I know
of anywhere for `__no_side_effects__`.  I guess it would be more accurate to
name it something like

    __ok_for_zeo_to_unpickle_this_when_decoding_a_msg__

I can't think of a sense in which it has something to do with side effects,
unless it means "this class promises that creating an instance won't have
any 'bad' side effects".

What I seem to be missing entirely here is why Zope ships Prefix instances
at the base ZEO msg level to begin with; maybe it's to call some method I
misunderstand (or haven't even bumped into yet <0.6 wink>).