On Sat, 14 May 2011 15:19:42 -0700, Glenn Linderman <v+pyt...@g.nevcal.com> wrote: > Looks great, conceptually. My only quibble is with the names > .source_value and .decoded: the names are clear, but lengthy (in > combination with stuff before the .). Other possibilities: > > .source_value: .orig .src .wf (wire format) > > .decoded: .value .dec .r (readable) > > On the other hand, it is only a quibble: I'm likely to only use this API > with email6 policies.
In a previous iteration of the API 'decoded' was indeed 'value', but I seem to have lost sight of that in the forest of the implementation :). On the other hand, source_value is the best description I could come up with. I started out with 'raw', but it isn't. It isn't 'wire format' for the same reason: it could come from either a bytes/wire format input, or from a unicode input. I'd be fine with 'orig', 'source' or 'src', and I don't really care what it is. The only code that should be accessing that attribute in the normal course of business is a generator. Feel free to bikeshed about it :) I will rename 'decoded' to 'value'. -- R. David Murray http://www.bitdance.com _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
