This makes me a little nervous because again it's a reimplementation of the logic of ``has_changed()`` and ``previous()``, but in loop form. As much as possible to avoid inconsistencies it would be good to have each concept represented clearly by one method that is reused internally; that is, the method ``has_changed`` should be the canonical arbiter of whether a given field has changed, and ``previous()`` should be in charge of giving its previous value; so for maintainability I'd rather see an implementation of ``changed()`` that loops over the fields and calls ``has_changed()`` and (if it has changed) ``previous()`` for each field. That will be slightly less efficient than this implementation, but I think it's worth it. You'd no longer have to special-case an unsaved instance in that case, because the behavior I described above for unsaved instances would just naturally fall out consistent with ``has_changed()`` and ``previous()``.