[Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch)

[SourceForge.net]

Bugs item #676072, was opened at 2003-01-28 08:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Vitecek (fufsource)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: rfc822.Message() doesn't support __contains__() (+patch)

Initial Comment:
class rfc822.Message() should behave like a dictionary
but it doesn't define method __contains__() so it's not
possible to use form:

   'header' in messageInstance

attached is a simple patch that fixes this.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-31 08:59

Message:
Logged In: YES 
user_id=12800

I'm still not crazy about the specific behavior requested by
this bug, i.e. that "header in msginst" should have meaning.
 But if everyone else wants this for rfc822.Message, I think
Raymond's patch is probably best since it's more thorough.

However, please add test cases and updates to the rfc822
documentation.

----------------------------------------------------------------------

Comment By: Michal Vitecek (fufsource)
Date: 2003-01-31 04:15

Message:
Logged In: YES 
user_id=698198

i don't know, but looking at the source from 2.2.2, there's a comment saying "Access as a dictionary (...)". in that case __contains__ should be implemented as well.

from my personal point of view it's inconsistent in its behaviour since GvR said '.has_key()' would most probably be deprecated in his 2002's talk and 'in' should be used instead.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-30 23:47

Message:
Logged In: YES 
user_id=80475

P.S.  when I said "someone", I was talking about all of the 
dictionary interface except for __contains__ which was 
added by me many months ago based on the idea that 
where there is a has_key, there should be a __contains__.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-30 23:35

Message:
Logged In: YES 
user_id=80475

Looking at the Py2.3 source, it looks like someone already 
implemented many of those dictionary semantics 
(including "header in msginst").

My thought was to complete this idea expressed in the 
comment,  "Access as a dictionary", which was followed by 
definitions for len, __getitem__, __setitem__, __delitem__, 
setdefault, has_key, __contains__, keys, values, and 
items.  So, it looked like it intended but did not succeed in 
implementing the entire dictionary interface.  My patch 
was a simple way to fill in the blanks.

OTOH, I have zero attachment to it and won't be 
disappointed if it is marked as Wont Fix and closed.
It never pays to spend much brainpower on a deprecated 
module.


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-30 22:41

Message:
Logged In: YES 
user_id=12800

It's not entirely clear to me that Messages should have
dictionary semantics, or that you should be able to say
"header in msginst".  I don't think I'd want those semantics
for email.Message.

Messages are more than just a collection of their headers. 
Why wouldn't __contains__ test for a subpart in a message
tree, or for some text in the body of the message?  Also, in
email.Message, __getitem__ etc don't have dict semantics on
purpose.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-30 18:40

Message:
Logged In: YES 
user_id=80475

I've attached my own version of this patch for Py2.3.
The same solution was used for shelve so that a
single minimal intervention keeps the module
fully synced with mapping interface.  I know this
module is superceded but it doesn't hurt to sync-up
its interface for those who still use it.

Barry, if it meets your approval please reassign
back to me.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470