[Python-checkins] cpython (2.7): Closes #10031: overhaul the "imports" section of the programming FAQ.
georg.brandl
python-checkins at python.org
Mon Oct 6 16:21:28 CEST 2014
https://hg.python.org/cpython/rev/9d321235f1f9
changeset: 92850:9d321235f1f9
branch: 2.7
parent: 92844:af18f1e1ade2
user: Georg Brandl <georg at python.org>
date: Mon Oct 06 16:21:08 2014 +0200
summary:
Closes #10031: overhaul the "imports" section of the programming FAQ.
Remove the advice to never use relative imports.
Remove the advice to locally import modules in __init__, it is a strange practice.
Remove the advice to use "from ... import *" with some modules.
files:
Doc/c-api/type.rst | 2 +-
Doc/faq/programming.rst | 20 +++++---------------
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/Doc/c-api/type.rst b/Doc/c-api/type.rst
--- a/Doc/c-api/type.rst
+++ b/Doc/c-api/type.rst
@@ -72,7 +72,7 @@
.. versionadded:: 2.2
This function only checks for actual subtypes, which means that
- :meth:`~type.__subclasscheck__` is not called on *b*. Call
+ :meth:`~class.__subclasscheck__` is not called on *b*. Call
:c:func:`PyObject_IsSubclass` to do the same check that :func:`issubclass`
would do.
diff --git a/Doc/faq/programming.rst b/Doc/faq/programming.rst
--- a/Doc/faq/programming.rst
+++ b/Doc/faq/programming.rst
@@ -438,9 +438,8 @@
-----------------------------------------------------------
In general, don't use ``from modulename import *``. Doing so clutters the
-importer's namespace. Some people avoid this idiom even with the few modules
-that were designed to be imported in this manner. Modules designed in this
-manner include :mod:`Tkinter`, and :mod:`threading`.
+importer's namespace, and makes it much harder for linters to detect undefined
+names.
Import modules at the top of a file. Doing so makes it clear what other modules
your code requires and avoids questions of whether the module name is in scope.
@@ -454,11 +453,10 @@
directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
3. locally-developed modules
-Never use relative package imports. If you're writing code that's in the
-``package.sub.m1`` module and want to import ``package.sub.m2``, do not just
+Only use explicit relative package imports. If you're writing code that's in
+the ``package.sub.m1`` module and want to import ``package.sub.m2``, do not just
write ``import m2``, even though it's legal. Write ``from package.sub import
-m2`` instead. Relative imports can lead to a module being initialized twice,
-leading to confusing bugs. See :pep:`328` for details.
+m2`` or ``from . import m2`` instead.
It is sometimes necessary to move imports to a function or class to avoid
problems with circular imports. Gordon McMillan says:
@@ -490,14 +488,6 @@
couple of dictionary lookups. Even if the module name has gone out of scope,
the module is probably available in :data:`sys.modules`.
-If only instances of a specific class use a module, then it is reasonable to
-import the module in the class's ``__init__`` method and then assign the module
-to an instance variable so that the module is always available (via that
-instance variable) during the life of the object. Note that to delay an import
-until the class is instantiated, the import must be inside a method. Putting
-the import inside the class but outside of any method still causes the import to
-occur when the module is initialized.
-
Why are default values shared between objects?
----------------------------------------------
--
Repository URL: https://hg.python.org/cpython
More information about the Python-checkins
mailing list