Running the setters at initialization causes two major problems:

* First, using the code in my unit test, during the initial construction
of the GetSet, "has_both" was set first. This caused the getter to fire
and correctly set updated_length_field to 1. Then, as the Django
initialization proceded, updated_length_field was set to the default of
0 since no value was passed in, and the computed value was blown away.
(Amusingly, the current end result is the same, the updated_length_field
is set to the default of 0. But now it's *documented* that setters
aren't called :) , rather than having setters run in an indeterminate
order on partially-constructed objects.)

* Suppose you have a setter that performs a transform T(x). The first
time you set it, you'll get T(x) in the database. The next time you
retrieve it, the setter applies the transform again, and you end up with
T(T(x)). Or to put it another way, loading an object and immediately
saving it is no longer an effective no-op. That's bad. (Putting it lightly.)

I started down a path to try to "solve" these problems, but everything
was complicated and made me nervous about performance issues.

I agree that adding that flag is sort of bad, but everything else I came
up with was worse. I'm open to suggestions.

A revised patch including documentation has been added; it supercedes
the previous one.