A 'message' part is not, in fact, a multipart in RFC terms.  (Only 'multipart' messages are multiparts.)  The email package models 'message' parts by making them single-element "multipart" messages, with the single element being a Message object representing the 'message' part's payload.

This is very useful; however, the fact that this is done should be documented in at least the is_multipart and walk methods.  As motivation for documenting this, consider a program that is looking for "the first part of type X" in a Message.  If an attached 'message' object has such a part, it would be discovered by a naive algorithm that uses 'walk', even though it is *inside* an attachment instead of part of the main message.  As for is_multipart, a naive reader of the documentation might expect that is_multipart would be true if and only if get_content_maintype == 'multipart', when this is in fact not true.

(I made these mistakes myself while implementing get_body and iter_parts in the new API additions.)

Hi David,
Will you please help me with the link?

If you are asking which documentation needs to be updated, it is:

   Doc/library/email.message.rst

The descriptions of the is_multipart method and the walk method.

Hello everyone,
I am working on this issue to create a patch.

Hi David,
I didn't exactly get the issue.Will you please help me with what is to be updated.

Well, probably the best thing to do to understand the issue is to look at the implementation of Message.walk and is_multipart, and to notice that "is_multipart()" can return a different answer than "msg.get_content_maintype() == 'multipart'" if the Message content type is "message/rfc822".  You may want to do some reading about how to construct Messages and experiment by creating such a message/rfc822 Message to really understand it.

I have tried to document the issue in the patch as discussed.

David: Do you think I should also add an example in walk() method
to demonstrate that it does not iterate over a 'message/rfc822' part
even though it is multipart?

Take a look at the source for msg_16.txt.  The last part is a message/rfc822, which encapsulates a text/plain message.  So it *does* iterate over it, even though it isn't a 'multipart' type (the opposite of what you say in the doc patch).

Explicitly pointing out this aspect of the existing example would be a good idea.

Sorry, my bad. I was a little confused. I have updated the patch and
also added the example explicitly.

Using _structure is a great idea.  I'm not so fond of the full example, but I'll have to contemplate the text to decide what I'd rather do.  Probably I'll take this patch of yours and tweak it, rather than try to tell you what I want :)  Thanks for the patch!

New changeset b717128799b5 by R David Murray in branch '3.4':
#18854: make it explicit that is_multipart does not mean 'multipart/xxx'.
https://hg.python.org/cpython/rev/b717128799b5

New changeset 9909de463dc9 by R David Murray in branch 'default':
Merge: #18854: make it explicit that is_multipart does not mean 'multipart/xxx'.
https://hg.python.org/cpython/rev/9909de463dc9

Thanks Abhilash.  I decided to use the full example after all, but tuned up the language a bit.