Still same bug even with email ver. 1.2

[Sheila King]

On Wed, 20 Mar 2002 01:55:38 -0500, barry at zope.com (Barry A. Warsaw)  wrote
about Re: Still same bug even with email ver. 1.2:

> 
> Thanks Sheila and David for their private email heads-up; I sadly
> don't have much time to follow c.l.py.  Also, thanks to Andrew for
> filing the SF bug.
> 
> >>>>> "SK" == Sheila King <usenet at thinkspot.net> writes:
> 
>     SK> OK, I got the latest email module from the CVS. I installed
>     SK> it. I ran the tests for the module. Everything tested out
>     SK> fine.
> 
>     SK> I now eagerly get out my code from last night, that was
>     SK> causing the 'int' has no attribute .lower error, and run it,
>     SK> hoping for different results.
> 
>     SK> No good. Same results. :(

Heh, well, technically my code did have errors, even if it pointed out
something to you in the email module code. <wink>
  
> The right fix is to clean up the messy semantics of
> Message.add_payload(), where the first time you call it, it will set
> the message's payload to the payload argument (a scalar), but the
> /second/ time you call it, it transforms the payload into a list, then
> appends the new payload to this list.
> 
> This is really pretty gross, and it rubbed me the wrong way when I
> designed it, but I didn't have any better ideas at the time so there
> you have it.  I believe this is the heart of the breakage.
> 
> What I think we ought to do is to deprecate Message.add_payload() but
> leave its semantics unchanged, change Message.attach() to not be an
> alias for add_payload(), and define the semantics of attach() to
> always set the payload to a list.  Thus, the first time you call
> attach().  I think attach() should retain the semantics that if the
> MIME type isn't multipart/* it should throw an exception (i.e. you
> can't attach() to a non-multipart; use set_type() first).
> 
> This means that if never set, a Message's payload would be None.
> After the first attach() it would be a list of length one, and
> subsequent attach()'ments would increase the length of the payload.
> 
> To get the old, initial semantics of add_payload(), you'd instead call
> set_payload() which always just sets the message's payload to the
> method's argument.  This would be used, for example, when you have a
> message/rfc822 MIME type and want to set the payload to an instance of
> a MIMEMessage, or if you have a image/gif and want to set the payload
> to an instance of MIMEImage.
> 
> For Python 2.3 (and for the next version of the standalone email
> package), I'd like to add a DeprecationWarning to add_payload(), then
> make the semantic change to attach().  The downside is that this might
> break code that relied on these semantics, however, I think if you had
> such an object tree, you wouldn't be able to use the Generator to
> flatten it anyway.  I'm open to suggestions here.

Most of the above sounds pretty good to me, and bear in mind that I am
certainly not as familiar with the mimelib/email package as many other
people who are also thinking about and reading this. However, isn't there
some way to not break code that currently relies on add_payload()?
Deprecate it, issue a warning, but ... maybe make add_payload() an alias
for attach() ? At least then it will issue intelligent error messages for
people using it. Just a thought...hmm, I can see holes in that suggestion,
too...

> There's a problem though: this isn't a change that should be made in
> Python 2.2.1!  It changes the API to the email package, and that
> should only be done in Python 2.3, IMO.

I agree.

> For Python 2.2, I /think/ I can fix Generator._handle_multipart() to
> watch out for subparts that are scalar[1].  If so, then the patch to
> the Parser described above probably ought to be backed out.  As long
> as the unit tests pass, I think we'd be okay.  This is probably a good
> patch to keep for Python 2.3, just to be safe.

This part is over my head ...(I understand it but don't get the
implications...)

> I'll try to work out a patch for Python 2.2.1 tomorrow.
> 
> Comments?

Thanks for looking into this. I'm so relieved to see someone else agree
that there are...well, things that need "polishing" about the email module.
I just love the idea of the whole package, and I really, really want to use
it!!!! :D

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/