The behaviour of the method for both classes seem to be a little different. Executing Parser.parse(fp) does not close the file pointer passed while Executing BytesParser.parse does.

I think this caused by fact that BytesParser.parse implementation is using with statement. Writing this

    fp = TextIOWrapper(file_pointer, encoding='ascii', errors='surrogateescape')
    with fp:
      return self.parser.parse(fp, headersonly)
    file_pointer.seek(0)

The original file_pointer gets closed and the call to seek fails.

I am not sure whether such behaviour is intended, and whether, the with behaves badly, or the TextIOWrapper, or the BytesParser, thus I am unable to suggest or provide a patch. But I think the behaviour should be consistent and/or documented.

I attached a file that depicts the issue. The problem originated from SO:
http://stackoverflow.com/questions/23599457/how-to-parse-an-email-in-python-without-closing-the-file
I think it's a minor issue, but it did cause a code to fail with no apparent reason.

I think the code should be using 'detach' after passing the fp to parser.parse, instead of using 'with'.

Here is the simple patch based on David Murray's thought.

Use try/finally to detach even if an exception is raised during parsing.

Thank you, Serhiy, for the review! Here is the updated patch.

Could you please add a test with parse() raising an exception?

Yet one nitpick. Instead of

        fp = openfile('msg_02.txt', 'rb')
        self.addCleanup(fp.close)
        ...

you can write

        with openfile('msg_02.txt', 'rb') as fp:
            ...

as in other tests.

Serhiy, here is the latest patch incorporating your request.

Sorry, I meant to test parser with invalid message, so that parse() raises an exception, and file shouldn't be closed after this.

The Parse class does not throw exception if given invalid message:

Assume /tmp/a.txt contains garbage, such as: "&&&&&"

With this code:

    with open("/tmp/a.txt", "r") as fp:
        msg = email.parser.Parser().parse(fp) # does not throw exception
        print(msg) # => &&&&&
        msg['from'] # => None

It is just you can not get useful information, such as msg['to'].

Right, part of the parser contract is to not throw exceptions. Traditionally, a bug could result in an exception, but not an invalid message.

However, using the new email policies, it is possible to *request* that it raise exceptions instead of registering defects. See policy.raise_on_defect.

If the parser itself doesn't raise exceptions, we should test with input stream raising an exception.

Ok, here is the updated patch based on R. David Murray's help. Thanks!

I believe there are msg_NN files that have defects. I'd rather use one of those in the exception test.

Here is the patch based on R. David Murray's nitpick.

New changeset 0a16756dfcc0 by R David Murray in branch '3.4':
bpo-21476: Unwrap fp in BytesParser so the file isn't unexpectedly closed.
http://hg.python.org/cpython/rev/0a16756dfcc0

New changeset a3ee325fd489 by R David Murray in branch 'default':
Merge bpo-21476: Unwrap fp in BytesParser so the file isn't unexpectedly closed.
http://hg.python.org/cpython/rev/a3ee325fd489

Thanks, Vajrasky. And to the reviewers as well.