I ran pyflakes on Python 3.5. Attached patch removes unused imports.

Sometimes, it's tricky to decide if an import is useless or if it is part of the API.

Strange example using import to define a method!
---

class Message:
    ...
    def get_charsets(self, failobj=None):
        ...
    # I.e. def walk(self): ...
    from email.iterators import walk

For the email module, I moved "from quopri import decodestring as _qdecode" from Lib/email/utils.py to email submodules where it used.

I made a similar change in multiprocessing for "from subprocess import _args_from_interpreter_flags".

Since "_qdecode" and "_args_from_interpreter_flags" are private functions, I don't consider that they were part of the public API.

Removing imports might reduce the Python memory footprint and speedup the Python startup.

Here's an alternative patch for the tarfile module.

IMO issue20976_tarfile.diff is useless.

LGTM. But for _qdecode you should ask RDM.

I would prefer that _qdecode be left alone.

New changeset f6f691ff27b9 by Victor Stinner in branch '3.4':
Issue bpo-20976: pyflakes: Remove unused imports
http://hg.python.org/cpython/rev/f6f691ff27b9

New changeset 714002a5c1b7 by Victor Stinner in branch 'default':
(Merge 3.4) Issue bpo-20976: pyflakes: Remove unused imports
http://hg.python.org/cpython/rev/714002a5c1b7

I would prefer that _qdecode be left alone.

Ok, I leaved these symbols unchanged in Lib/email/utils.py even if they are not used:

from quopri import decodestring as _qdecode
from email.encoders import _bencode, _qencode

On Mar 20, 2014, at 08:29 AM, STINNER Victor wrote:

from quopri import decodestring as _qdecode
from email.encoders import _bencode, _qencode

AFAICT, _qdecode is only used in email/messages.py, so perhaps it's better to
import it there and remove it from utils.py?

_bencode and _qencode are imported/defined and used in encoders.py. It
doesn't seem like utils.py or any other code uses them.

They're all non-public so why not clean it up?

Well, one reason is I was afraid mailman might be using them. So if you are cool with it, that removes that objection.

The other reason was that it seemed they were being used "from" utils on purpose, as a design thing. I did not take the time to do a full analysis, since Victor wanted to get his patch in.

So, if you've taken a look and you think there's no reason to keep them the way they are, then I'm fine with it.

Barry, David: It's up to you. I'm done with this issue, but you can drop more unused import if you want. Since I don't know well the email module, I don't want to be responsible of breaking it :-)

On Mar 20, 2014, at 01:32 PM, R. David Murray wrote:

Well, one reason is I was afraid mailman might be using them. So if you are
cool with it, that removes that objection.

Nope, neither the 2.1 or 3.0 code uses those methods AFAICT.

The other reason was that it seemed they were being used "from" utils on
purpose, as a design thing. I did not take the time to do a full analysis,
since Victor wanted to get his patch in.

I suspect it's just left over cruft from the early days of the email/mimelib
code.

So, if you've taken a look and you think there's no reason to keep them the
way they are, then I'm fine with it.

Do you want the honors? :)

Sure.

New changeset 5d645f290d6a by R David Murray in branch '3.4':
bpo-20976: remove unneeded quopri import in email.utils.
http://hg.python.org/cpython/rev/5d645f290d6a

New changeset d308c20bf2f4 by R David Murray in branch 'default':
Merge bpo-20976: remove unneeded quopri import in email.utils.
http://hg.python.org/cpython/rev/d308c20bf2f4