This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Update pep8 to specify explicitly 'module level' imports at top of file
Type: enhancement Stage: resolved
Components: Documentation Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: docs@python Nosy List: IanLee1521, barry, docs@python, ezio.melotti, nanjekyejoannah, ncoghlan, pas, rhettinger, terry.reedy
Priority: normal Keywords: patch

Created on 2014-12-16 04:24 by IanLee1521, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
pep-0008.patch IanLee1521, 2014-12-16 04:24
Messages (9)
msg232708 - (view) Author: Ian Lee (IanLee1521) * Date: 2014-12-16 04:24
Minor update pep8 to specify explicitly that "Imports at top of file" refers specifically to module level imports, per input from Nick Coghlan @
msg232949 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-12-19 22:06
I read Nick's post and I would like PEP8 to continue to discourage imports at class scope unless there is actually a use case.  I discovered yesterday that idlelib.ColorDelegator has several imports at the top of the module and more as the top of the class (of the same name).  I cannot think of any good reason for the split.
msg233011 - (view) Author: Ian Lee (IanLee1521) * Date: 2014-12-22 06:04
So one concern that was brought up on GitHub was the fact that currently this is not actually followed universally in the Python standard library. In particular there are 636 errors in the standard library ``python --select E402 --statistics /usr/lib/python3.4``.

The vast majority are due to issues with dunder definitions ``__{all,author,copyright,credits,version,etc...}__`` before the imports. A lesser cause is imports in the middle of files. ``Lib/`` has pretty much all of these issues. In particular ``__all__`` is specifically mentioned that it should be declared AFTER the imports by PEP-8. That said, I would argue this is a good time to clean up that code in the standard library.

Additionally, its possible that there might need to be some wording in the PEP about intermixing "try,except,else,finally" and possibly "if,elif,else" into the imports. E.g. 

    import unittest2
    import unittest

if sys.platform == 'win32':
    import foo
msg233012 - (view) Author: Ian Lee (IanLee1521) * Date: 2014-12-22 06:37
I should add that I would be happy to patch the standard libraries to be compliant w.r.t. the imports at top of the files.
msg233065 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-12-23 23:16
> I would argue this is a good time to clean up that code in the standard library.

Please leave any clean-ups to the module maintainers.  PEP 8 is something you should do to your own code, rather than something you inflict on other people's code.

We generally leave "clean-ups" to the module maintainers rather than creating code churn which can make it more difficult to apply actual bug fixes across versions.

Also, GvR has long expressed a preference for "holistic refactoring" where we avoid making superficial changes across the library and reserve those changes for occasions where we're thinking more deeply about a specific piece of code.  The basis for this viewpoint has been confirmed a number of times when we've received Pep 8 patches that introduced bugs into code that was previously correct.
msg267012 - (view) Author: Ian Lee (IanLee1521) * Date: 2016-06-03 00:47
Are there any other concerns with the patch that I would be able to clean up?
msg350416 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2019-08-25 00:50
Since this is a PEP related issue, it should be moved to the PEP Github repository here : . If it still exists.
msg350420 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-08-25 02:21
At least some idlelib imports are delayed to avoid circular import errors, as described by Nick.

The patch adds 'Module level' before 'imports'.
Pro: techinically correct as only module level imports can be put at the top.
Com: might be seen as giving too much license to putting imports elsewhere.

Raymond, what do you think?  If you are not 'pro' enough to make the change, I think we should close.
msg350421 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-08-25 02:39
I concur that this should be closed.
Date User Action Args
2022-04-11 14:58:11adminsetgithub: 67250
2019-08-25 02:39:39rhettingersetstatus: open -> closed
resolution: rejected
messages: + msg350421

stage: resolved
2019-08-25 02:21:52terry.reedysetmessages: + msg350420
2019-08-25 00:50:57nanjekyejoannahsetnosy: + nanjekyejoannah
messages: + msg350416
2016-06-03 00:47:47IanLee1521setnosy: + barry
messages: + msg267012
2016-02-19 16:37:41passetnosy: + pas
2014-12-23 23:16:53rhettingersetnosy: + rhettinger
messages: + msg233065
2014-12-22 06:37:23IanLee1521setmessages: + msg233012
2014-12-22 06:16:07ezio.melottisetnosy: + ezio.melotti
2014-12-22 06:04:40IanLee1521setmessages: + msg233011
2014-12-19 22:06:11terry.reedysetnosy: + terry.reedy
messages: + msg232949
2014-12-16 04:24:24IanLee1521create