The mimetools module has been deprecated for ages, but it is still used in 
multiple places (a quick grep lists ``cgi``, ``httplib``, ``urllib``, 
``urllib2``, ``test_cookielib``, ``test_multifile``, ``test_urllib``, 
``test_urllib2``, ``test_urllib2net``, ``test_urllib_localnet``, 
``test_urllibnet``, ``test_xmlrpc``). All uses need to be removed before 
the module can go from Py3K.

mimetools.Message is compatible with email.message.Message, right?

I don't know how compatible it is.

The APIs are bit different, but it should be possible to migrate from 
the old to the new.  All the key functionality is there.

Barry, any thoughts on transitioning away from the deprecated modules?

The only use of mimetools inside cgi is in parse_multipart, which is 
untested and has huge warnings like these ones:

"""
XXX This does not parse nested multipart parts -- use FieldStorage for
that.

XXX This should really be subsumed by FieldStorage altogether -- no
point in having two implementations of the same parsing algorithm.
Also, FieldStorage protects itself better against certain DoS attacks
by limiting the size of the data read in one chunk.  The API here
does not support that kind of protection.  This also affects parse()
since it can call parse_multipart().
"""

I'm sending a patch that removes mimetools from urllib and test_urllib. It 
now returns an email.message.Message instead of mimetools.Message.

I also moved some imports to the top of the file. If that's a problem, I 
can send another patch.

It's relatively easy to replace mimetools in most places: it's just a 
matter of changing mimetools.Message to email.message_from_file, but it 
gets a lot more complicated when there's inheritance involved.

The problem is that mimetools.Message is both a parser and a Message 
representation, and AFAIK there's no single class in ``email`` which does 
both -- the functionality is split between the Parser and Message classes.

Inheritance happens in two places: ``pydoc.Message`` and 
``http.client.HTTPMessage``, and I couldn't find a solution for those 
cases yet. Any help would be appreciated.

One idea:  in http.client.HTTPMessage, inherit from email.Message, 
modify the addheaders/addcontinue/readheaders methods to use the 
methods in Message.   Then, change the instantiation in HTTPResponse to 
self.msg = email.parser.Parser(_class=HTTPMessage).parsestr(io.BytesIO
()).  

Something similar may apply to pydoc.  FYI, I believe there is a 
pending discussion about whether to keep pydoc in Py3.0.

Attached a patch to rename all calls to the mimetools-specific 
.getheader() to .get(), which works on both libraries (mimetools and 
email.Message). That eases transition without breaking any tests.

As we're moving away from using .getheader() everywhere (file 10538), I 
think it's a good time to make HTTPResponse conform to PEP8 and define 
.get_header (with underscore) instead.

-1 on the get_header() change.  I would like this patch to be as 
minimal as possible.  The new spelling is a bit awkward and it 
introduces an unnecessary change that could break code.

Raymond, thanks for the parser solution! It worked -- just broke some 
tests because of the nature of FeedParser. While rfc822.Message can read 
the file and stop at some point in the middle (meaning that self.fp can 
still be read), FeedParser will always read the whole file *and* close 
it, even if setting _headersonly to True. This is the same problem that 
I had to work around on issue 2849. I'm attaching a patch that 
demonstrates it: lots of tests giving "I/O operation on closed file."

Right now I can think of two options:
 * Working around it, again (don't know how)
 * Implement some flag in FeedParser to make it consume only the headers 
and leave the file open.

Any other idea?

Oh, and if you think it's better not to mess with the name of other 
methods like getheader, that's fine by me. It was only a suggestion, 
after all. ;)

mimetools removal is almost complete, with the exception of only two 
broken tests: test_urllib2_localnet and test_xmlrpc. I'm not sure if it 
can make it to this beta, but at least it's really close.

Barry, can you take a look at this?
Ideally, it should go it before the beta
so it can get thoroughly exercised.

This patch works for me in Python 3.0.  It's basically Humberto's patch
with the two failing tests fixed.

Actually, try this one.

r64164 in Python 3.0.  This doesn't apply cleanly to Python 2.6; could
someone please back port it?

On Wed, Jun 11, 2008 at 11:09 PM, Barry A. Warsaw
<report@bugs.python.org> wrote:
>
> Barry A. Warsaw <barry@python.org> added the comment:
>
> r64164 in Python 3.0.  This doesn't apply cleanly to Python 2.6; could
> someone please back port it?

Why does it need to be in 2.6? mimetools is still there.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jun 12, 2008, at 8:57 AM, Benjamin Peterson wrote:

> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> On Wed, Jun 11, 2008 at 11:09 PM, Barry A. Warsaw
> <report@bugs.python.org> wrote:
>>
>> Barry A. Warsaw <barry@python.org> added the comment:
>>
>> r64164 in Python 3.0.  This doesn't apply cleanly to Python 2.6;  
>> could
>> someone please back port it?
>
> Why does it need to be in 2.6? mimetools is still there.

I guess you're right, it doesn't.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSFEfD3EjvBPtnXfVAQKrBwQAoOOjFenHlq0DVEtfeVSuG5/rPWHrzfQw
OwoSlYWa5zkqWqjFdRG780rElbfAjgtz3J7Od8HENxUfsHBvH3bFM0PZCLSQRZMI
UVP8dM1KIcBDOZoQPMoahM1Q7l16iCsayhauWEnJP2MIVje7D/rXO9jjpkQixRyi
3wkfmkNin0k=
=gAB6
-----END PGP SIGNATURE-----

This is done.

> Why does it need to be in 2.6? mimetools is still there.

Because it outputs a warning with python2.6 -3, it's annoying for people
trying to port their application to python3k

Benoit has a good point, so I have opened this issue again so we can get
2.7 even closer to 3.x compatibility.

Closing as outdated since 2.7 has been release with some mimetools usage left.

resolution: out of date
stage: resolved