On 5/16/2011 1:24 PM, R. David Murray wrote:
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'.
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.
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
