On Apr 10, 2009, at 1:19 AM, firstname.lastname@example.org wrote:
On 02:38 am, email@example.com wrote:
So, what I'm really asking is this. Let's say
you agree that there
are use cases for accessing a header value as either the raw
encoded bytes or the decoded unicode. What should this return:
The raw bytes or the decoded unicode?
My personal preference would be to just get deprecate this API, and
get rid of it, replacing it with a slightly more explicit one.
This is pretty darn clever Glyph. Stop that! :)
I'm not 100% sure I like the name .bytes_headers or that .headers
should be the decoded header (rather than have .headers return the
bytes thingie and say .decoded_headers return the decoded thingies),
but I do like the general approach.
headers. Sometimes you have some unicode thing and
sometimes you have some bytes. You need to end up with bytes in
the ASCII range and you'd like to leave the header value unencoded
if so. But in both cases, you might have bytes or characters
outside that range, so you need an explicit encoding, defaulting to
message.headers['Subject'] = 'Some text'
should be equivalent to
message.headers['Subject'] = Header('Some text')
Yes, absolutely. I think we're all in general agreement that header
values should be instances of Header, or subclasses thereof.
My preference would be that
message.headers['Subject'] = b'Some Bytes'
would simply raise an exception. If you've got some bytes, you
should instead do
message.bytes_headers['Subject'] = b'Some Bytes'
message.headers['Subject'] = Header(bytes=b'Some Bytes',
Explicit is better than implicit, right?
Again, I really like the general idea, if I might quibble about some
of the details. Thanks for a great suggestion.