title: Protobuf defaults vs. "missing required fields" when serializing
body: <p>The SerializeToString() method on a ProtoBuf message containing required fields, that have defaults, always throws the <code>EncodeError</code> stating that the message is missing those required fields.  However if I check the value of the fields, all defaults are set.  For example:</p>
  
  <pre><code>// mymessage.proto
  message MyMessage {
      required int32 val = 1 [default=18];
  }
  </code></pre>
  
  <p>Then in python:</p>
  
  <pre><code>from mymessage_pb2.py import MyMessage
  m = MyMessage()
  print m.val # Shows m.val == 18
  print m.SerializeToString() # EncodeError
  </code></pre>
  
  <p>On the other hand if I do this:</p>
  
  <pre><code>m.val = m.val
  print m.SerializeToString() # No Error
  </code></pre>
  
  <p>So clearly, it's just needing each field to get touched despite having a default value on initialization.  For me, one of the major points of having defaults was to only require someone to update the non-default fields (or those fields they need to change), so this set-it-to-itself method is a pretty sorry solution.  </p>
  
  <p>Marking the fields as <code>optional</code> is not a solution since these fields are legitimately required per our spec.</p>
  
  <p><strong>UPDATE:</strong> My attempt at a work-around included MergeFrom and CopyFrom, but neither worked.  So I wrote this:</p>
  
  <pre><code>def ActuallyInit(obj):
      err = []
      obj.IsInitialized(err)
      for field in err:
          attr = obj.__getattribute__(field)
          try:
              obj.__setattr__(field, attr)
          except:
              ActuallyInit(attr)
  </code></pre>
  
  <p>Then one creates their protobuf object and passes it into <code>ActuallyInit</code> which recursively sets each field to itself.  This seems like an ugly hack, so I'm leaving the question below open.</p>
  
  <p><strong>QUESTION:</strong> Is there a way to create the ProtoBuf message instance and "convince" it that every already-initialized-to-default field is in-fact not an error?</p>