[Zope3-dev] trigger persistence

[Jeremy Hylton]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

  GvR> OTOH one could claim it exposes more internal details of the
  GvR> persistence mechanisms.  If in the future the persistence API
  GvR> changes (e.g. you'd have to call self._p_changed(), or
  GvR> whatever), the latter solution would break, while the former
  GvR> idom would (presumably) still work.

The _p_changed is part of the external API, not an internal detail.
I'd be happy to change all the code that uses the explicit interface
if it changes.

What if we wanted to make setattr() smart and not mark an object as
changed if the actual binding of the attribute doesn't change?  I'd
say the trick of depending on implicit effects of attribute assignment
depends more on internal details.

Jeremy