[MERGE] An EmailMessage class for bzrlib (v3)

[Martin Pool]

On 7/16/07, Adeodato Simó <dato at net.com.org.es> wrote:
> Hm. This seemed the lesser of two evils to me. Let me see if I understand
> your facade concept: a class that, depending on whether there's an attachment
> or not, is internally a MIMEMultipart object, or a simple Message.
>
> I can think of two ways of doing this:
>
>   * try to behave like a true Message/MIMEMultipart, that is, the
>     creator of the object can do msg['From'] = 'Foo', etc., and use all
>     the methods available in the standard Message/MIMEMultipart classes.
>     For this, I guess one would have to play with __getattr__().
>
>   * lock down the API of EmailMessage, reducing it to the constructor,
>     and add_inline_attachment(). The creator cannot play with it. This
>     sounds more sensible, an less error-prone.
>
> Is either of this what you prefer, or something different altogether? In
> the constructor a Message() instance is created, and there is code in
> add_inline_attachment() to move from that instance to a MIMEMultipart()
> one the first one that method is called.

Aaron's explanation of the Facade pattern is the one I meant.  What I
recommend is more like your second case.  To be more precise it's not
that it "is internally" one or the other, but rather that it contains
one or the other as appropriate.

The question is whether we would need access to the full richness of
the underlying classes.  It seems like we don't?

>
> > +
> > +    @staticmethod
> > +    def string_with_encoding(string):
> > +        """Return a str object together with an encoding.
> > +
> > +        :param string: A str or unicode object.
> > +        :return: A tuple (str, encoding), where encoding is one of 'ascii',
> > +            'utf-8', or '8-bit', in that preferred order.
>
> > Having automatic behaviour depending on whether something is a unicode or
> > str object has been a bit problematic in the past.  Would it be feasible
> > to have different interfaces and insist on the caller knowing whether
> > they're putting in binary, ascii or unicode data?
>
> Well, it was already agreed that add_inline_attachment(), and the body
> parameter of the constructor, would accept either unicode or str,
> sending as utf-8 and 8-bit, respectively. This function is, as explained
> in the comment right below the docstring (copying it below for
> convenience), only a step further because of how Python's email module
> behaves. I'd rather keep it if possible, makes things more convinient.
> (If it goes away, the only thing that changes is that EmailMessage
> objects will *always* be base64-encoded.)

OK

> Just let me know what way to move on to get this hopefully merged some
> day. ;-)

Basically: change your EmailMessage to not subclass MIMEMultipart, but
rather to internally contain either a Message or MIMEMultipart as
appropriate.  (I think I have the right classnames there, but
hopefully you get the idea.)

-- 
Martin