[MERGE] An EmailMessage class for bzrlib (v0)

[Adeodato Simó]

* Aaron Bentley [Mon, 25 Jun 2007 09:47:27 -0400]:

> Adeodato Simó wrote:
> > Here is my proposed EmailMessage class for bzrlib. I think I addressed all
> > the comments raised in the [RFC] thread.

> I don't think you've addressed my comment that add_text_attachment is
> overgeneral.  In order to support two usages, you're contorting the
> meaning of "text".  I think it's better to have two methods-- one for
> each usage.

I really dislike the idea of having two separate methods to do
conceptually the same thing: add a part which is meant to be displayed
inline. Whether it has an encoding or not, seems a minor detail to me.

Would it help to your objection if the method was called "add_inline_attachment"?
(Or some other variation with "inline" instead of "text".) I think that
can be a reasonable compromise...

> >   * Aaron, I agree to adding the EmailMessage.send() method you
> >     proposed; but since it would need SMTPConnection, which is not yet
> >     merged, I'm delaying its inclusion until then (*hint*).

> Done.

Thanks, EmailMessage.send() added.

> > +            # This does not put the name part in double quotes if it
> > +            # contains forbidden unquoted chars, eg. a dot. TODO?
> > +            return '%s <%s>' % (Header.Header(safe_unicode(user)), email)

> Is there any harm in always double-quoting?  That's what I do, even
> though my name contains no forbidden characters.

I found email.Utils.formataddr, which adds quotes when necessary, so I
moved the code to use that.

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Man: Wow, that woman looks exactly the way Nina is going to look in
about ten years... Oh shit, it is Nina. Don't tell her what I said, okay?
                -- http://www.overheardinnewyork.com/archives/003086.html