Hi,

The following script shows two problems with email.mime.text.MIMEText:

- first the use of msg['To'] seems confusing because its dictionnary-like syntax made me think it acts as a "set or replace", but in fact is working as a stream operation
- second this behavior allows for the same field to be repeated several times in a header which is discouraged in rfc-822 and forbidden for many fields in rfc-2822. 



#########################################"
from email.mime.text import MIMEText

msg = MIMEText("""Hello World""")

dest = ["one@example.com", "two@example.com", "three@example.com", "four@example.com"]
 
for d in dest:
    msg["From"] = "myself@example.com"
    msg["To"] = d
    msg["subject"] = "just a test"
    print (msg)
    # + send the buggy mail...
###################################

the last sent mail will looks like this: 

---------------------
Hello World
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: myself@example.com
To: one@example.com
subject: just a test
From: myself@example.com
To: two@example.com
subject: just a test
From: myself@example.com
To: three@example.com
subject: just a test
From: myself@example.com
To: four@example.com
subject: just a test

Hello World
----------------------


I see some possible modifications:

* make the [] operator work as a dictionnary-like syntax. So calling msg['To'] multiple times would simply replace the previous 'To:' field. The additional constraint is that some fields like 'comments' or 'keywords' can be repeated

* (or) throw an error when some fields are repeated in this list: 
  from,  sender, reply-to, to, cc, bcc, message-id, in-reply-to, references, subject

The behaviour you observe is by design, and documented.  The email package needs to be able to handle RFC-invalid input, which includes messages with multiple instances of fields that are supposed to be singletons.  It also needs to keep track of the order of headers.  Thus its interface is, as documented, a "mapping-like" interface with duplicable keys and an element order.

That said, it would be a valid feature request to have a way to have it generate errors if a field that is supposed to be a singleton per-RFC is added more than once.  This will require a registry of such headers...a registry of headers is planned for the next version of the email package (email6), so that would be an appropriate time for this to be implemented.  email6 will also have strict and lenient modes, which will also be useful in this context.

I think really ill/strange is that kind of item _assignments_  do _add_ multiple.

If   msg[field] = xy    would just add-first/replace-frist , and only msg.add_xxxx/.append(field, xy)  would  add multiples that would be clear and understandable/readable. 
(The sophisticated check dictionary is unnecessary IMHO, I don't expect the class to be ever smart enough for a full RFC checklist.)

e.g. I remember a bug like

msg[field] = xy
if special_condition:
     msg[field] = abc   # just wanted a alternative


Never ever expected a double header here!

"="  with adding behavior is absurd IMHO. Certainly doesn't allow readable code.

Regardless of what anybody thinks about the design, it is what it is and can't be changed for backward compatibility reasons.  The best we can do is reject creating duplicate headers for headers that may only appear once.  That feature has already been coded in the new version of the email package (see http://pypi.python.org/pypi/email), but has not yet been committed to the trunk, which is why this issue is still open.