Re: [Email-SIG] Plans for email 6.0

2009-04-02 Thread Tony Nelson
At 07:54 -0500 2009/04/02, Barry Warsaw wrote: ... ...Here's a rambling of some of my thoughts on things we should do. ... * Bytes and string interfaces. This is the trickiest one. I think that internally, header names and values, and payloads should all be represented as bytes. But APIs

Re: [Email-SIG] Email 6.0

2009-04-05 Thread Tony Nelson
At 13:26 -0400 04/05/2009, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've started a branch for the email package version 6.0.0. Given that we have until May 2nd to solidify this thing for Python 3.1, I honestly don't think we'll make it. I would rather concentrate on

Re: [Email-SIG] Append behavior of __setitem__

2009-04-11 Thread Tony Nelson
At 16:43 +0900 04/11/2009, Stephen J. Turnbull wrote: Barry Warsaw writes: So I'm just starting to read RFC 5322 and I'm starting by skimming over Appendix A (differences between RFC 5322 and 2822). I know Barry's a big supporter of the Postel Principle. As a guideline[1], how far back

Re: [Email-SIG] Append behavior of __setitem__

2009-04-13 Thread Tony Nelson
At 10:04 -0400 04/13/2009, Barry Warsaw wrote: ... We could potentially have strict and lenient modes, or possible RFC 822, 2822, 5322 modes. Is there any need to produce emails that don't conform to the latest spec? Those specs are crafted to produce backward-compatible messages. OTOH, I feel

Re: [Email-SIG] Append behavior of __setitem__

2009-04-13 Thread Tony Nelson
At 10:05 -0400 04/13/2009, Barry Warsaw wrote: On Apr 11, 2009, at 5:17 PM, Tony Nelson wrote: Sure. The header field should be parsed, if possible, and possibly add a defect to the message. For some header fields, the data should be added to the previous Header instance; for others, an extra

Re: [Email-SIG] [Python-Dev] Dropping bytes support in json

2009-04-13 Thread Tony Nelson
At 10:11 -0400 04/13/2009, Barry Warsaw wrote: On Apr 10, 2009, at 11:08 AM, James Y Knight wrote: Until you write a parser for every header, you simply cannot decode to unicode. The only sane choices are: 1) raw bytes 2) parsed structured data The email package does not need a parser for

Re: [Email-SIG] API for Header objects [was: Dropping bytes support in json]

2009-04-14 Thread Tony Nelson
At 18:11 +0900 04/14/2009, Stephen J. Turnbull wrote: Tony Nelson writes: Assuming that by Destination you mean a class of Address header fields, as there is no Destionation: header field, such header fields contain addresses, which can be considered to contain (as the email package does

Re: [Email-SIG] API for Header objects [was: Dropping bytes support in json]

2009-04-16 Thread Tony Nelson
At 23:02 +1000 04/16/2009, Steven D'Aprano wrote: On Thu, 16 Apr 2009 10:39:52 am Tony Nelson wrote: I don't want there to be any str(msg['tag']) or bytes(msg['tag']) at all, so there would be no loss of consistency. That's ... different. Messages need flattening to bytes

Re: [Email-SIG] API for Header objects [was: Dropping bytes support in json]

2009-04-17 Thread Tony Nelson
At 00:13 +0900 04/18/2009, Stephen J. Turnbull wrote: R. David Murray writes: put Header objects into it. I don't think the overhead of having to do message['Subject'] = Header('subject string') Hm. Should a Header know which header it is? Ie, should that be

Re: [Email-SIG] API for Header objects

2009-04-17 Thread Tony Nelson
At 19:04 +0900 04/17/2009, Stephen J. Turnbull wrote: Tony Nelson writes: This example seems tortured and contrived. Not at all. I currently use grep, not the email package, but in fact I extract several headers for use in mailing list moderation. It's getting to the point where my gradually