[Email-SIG] [Python-Dev] Dropping bytes "support" in json
barry at python.org
Fri Apr 10 18:56:09 CEST 2009
On Apr 10, 2009, at 1:19 AM, glyph at divmod.com wrote:
> On 02:38 am, barry at python.org 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:
>> >>> message['Subject']
>> 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.
>> Now, setting 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
>> utf-8 probably.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 304 bytes
Desc: This is a digitally signed message part
More information about the Email-SIG