classification
Title: email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added.
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Sharebear, facundobatista
Priority: normal Keywords:

Created on 2008-01-14 10:54 by Sharebear, last changed 2008-01-19 12:36 by facundobatista. This issue is now closed.

Files
File name Uploaded Description Edit
issue1822.patch Sharebear, 2008-01-19 11:43 Proposed patch
Messages (3)
msg59895 - (view) Author: Jonathan Share (Sharebear) Date: 2008-01-14 10:54
Steps to reproduce
==================
>>> from email.mime.multipart import MIMEMultipart
>>> foo = MIMEMultipart()
>>> foo.is_multipart()
False

Expected Result
===============
True should be returned from MIMEMultipart.is_multipart()

Notes
=====
Looking at the implementation of is_multipart() in email.Message it 
would appear that if self._payload was initialised to an empty list in 
the constructor of MIMEMultipart when _subparts is None, this would be 
a sufficient fix for this issue.

However, from an outsider looking into this code for the first time, 
this doesn't look like the best architecture, shouldn't the issue of 
whether a message has multiple parts, and logic specific to this be 
handled through inheritance. With the current implementation the 
superclass makes assumptions about how a subclass is implemented, this 
just feels wrong. Have I missed something, is there a good reason for 
things being as they are today?

Feel free to take the discussion to the python-dev list, I have just 
subscribed, and I am interested in fixing this issue myself in the next 
bug day if someone can answer my questions above.
msg60153 - (view) Author: Jonathan Share (Sharebear) Date: 2008-01-19 11:43
Attaching a patch for the quick fix I proposed below.

I would still like to see some feedback regarding making the design of 
the mime module more object oriented. email.Message really shouldn't be 
making assumtions about how subclasses represent their state.
msg60154 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2008-01-19 12:36
Fixed in r60073.

Regarding the flag, you're right: maybe these classes should deal it in
other way... but maybe there're reasons to do this.

If you want to push a better structure for this flag, feel free to raise
the issue in python-dev.

Anyway, the real problem, here, is fixed, :)
History
Date User Action Args
2008-01-19 12:36:30facundobatistasetstatus: open -> closed
resolution: fixed
messages: + msg60154
2008-01-19 11:49:48Sharebearsetnosy: + facundobatista
2008-01-19 11:43:55Sharebearsetfiles: + issue1822.patch
messages: + msg60153
2008-01-14 10:54:54Sharebearcreate