Tiny difficulty with `multifile'

[François Pinard]

Hi, people.  Just do not pay much attention to this message, unless you
feel like taking a rest of your own problems with the problem of someone
else :-).  This is not an important matter, anyway.

I'm trying to use Python to study MIME submissions (my goal is to give
that ability to the TP robot), and am very pleased to discover how easy
it is to study complex messages with the Python libraries.  I'm teased
by something I do not understand (yet I can easily work around it), and
I wonder if some of you will be kind enough to explain this little matter
to me.  First, here is the code I use for testing:

---------------------------------------------------------------------->
import mimetools, multifile

def essai():
    mime_walk(walker, multifile.MultiFile(open('/tmp/message2')))

def mime_walk(walker, file, level=0):
    entity = mimetools.Message(file)
    if entity.getmaintype() == 'multipart':
        boundary = entity.getparam('boundary')
        if boundary:
            file.push(boundary)
            mime_walk(walker, file, level + 1)
            try:
                while file.next():
                    mime_walk(walker, file, level + 1)
            except multifile.Error:
                pass
            file.pop()
    elif entity.gettype() == 'message/rfc822':
        mime_walk(walker, file, level + 1)
    else:
        walker(entity, file, level)

def walker(entity, file, level):
    print '%s%d. %s; %s; %s' \
          % (' ' * 2 * level, file.level,
             entity.gettype(), entity.getplist(), entity.getencoding())

essai()
----------------------------------------------------------------------<

Given a message having this structure (shown with Pterodactyl Gnus):

---------------------------------------------------------------------->
920828    [ 367: beatty at COSMOS.VLSI.C] <* mixed> mew-law encoding?
920828        [  12: beatty at COSMOS.VLSI.C] <1 richtext>
920828        [ 325: beatty at COSMOS.VLSI.C] <2 rfc822>
920826            [ 309: Derek Beatty        ] <2.* mixed> mail from Wacky
920826                [   7: Derek Beatty        ] <2.1 text> index.rtf
920826                [ 284: Derek Beatty        ] <2.2 audio> VoiceMail_beatty0.vox
920826                [   0: Derek Beatty        ] <2.3 text>
920828        [   5: beatty at COSMOS.VLSI.C] <3 richtext>
----------------------------------------------------------------------<

the above Python code yields:

---------------------------------------------------------------------->
  0. text/plain; []; 7bit
  0. text/richtext; []; quoted-printable
      0. text/plain; []; 7bit
      0. text/plain; ['type=microsoft-rtf', 'name=index.rtf']; 7bit
      0. audio/basic; ['name=VoiceMail_beatty0.vox']; base64
      0. text/plain; []; 7bit
  0. text/richtext; []; quoted-printable
----------------------------------------------------------------------<

and I wonder why `file.level' invariably prints as `0'.  The level I
maintain myself is not, as shown by the variable margin.  Should I do
anything special to protect the level within the MultiFile?  I thought that
`file.push' and `file.pop' would have done it automatically, but apparently,
I miss something.

Oh, for those who might wonder, I added the `try:' clause because there
is a MIME formatting error in the original message -- the closing boundary
is missing at the end of the quoted `message/rfc822', before resuming the
outer structure, and I wanted to be immune to such errors.  I also think
that there might also be faked entities which are purely white, and which
Gnus knows how to ignore.  I'll investigate this a bit later.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard