Re: headers everywhere

On 5/16/2011 1:24 PM, R. David Murray wrote:
> On Sat, 14 May 2011 15:19:42 -0700, Glenn Linderman<[email protected]>  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'.

Given than, 'orig' or 'src' bubble to the top of my list of preferences.

Seems like in modes with mixed email library versions, these are 
recommended for regular use, possibly beyond generators, so that's why 
their length stuck out to me as a possible issue.