mirrors/cpython
0
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2024-11-27 11:55:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

merge with 3.4

Browse Source
This commit is contained in:
Georg Brandl 2014-10-06 16:19:20 +02:00
commit 4f8fed28f0
2 changed files with 8 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Doc/faq/programming.rst
View File

@ -292,9 +292,8 @@ What are the "best practices" for using import in a module?
-----------------------------------------------------------
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.
@ -308,11 +307,6 @@ It's good practice if you import modules in the following order:
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
write ``from . import m2``, even though it's legal. Write ``from package.sub
import m2`` instead. See :pep:`328` for details.
It is sometimes necessary to move imports to a function or class to avoid
problems with circular imports. Gordon McMillan says:
@ -343,14 +337,6 @@ module, but loading a module multiple times is virtually free, costing only a
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?
----------------------------------------------

8
Makefile.pre.in
View File

@ -343,7 +343,8 @@ AST_C= $(AST_C_DIR)/Python-ast.c
AST_ASDL= $(srcdir)/Parser/Python.asdl
ASDLGEN_FILES= $(srcdir)/Parser/asdl.py $(srcdir)/Parser/asdl_c.py
# XXX Note that a build now requires Python exist before the build starts
# Note that a build now requires Python to exist before the build starts.
# Use "hg touch" to fix up screwed up file mtimes in a checkout.
ASDLGEN= @ASDLGEN@ $(srcdir)/Parser/asdl_c.py
##########################################################################
@ -1509,7 +1510,10 @@ TAGS::
etags Include/*.h; \
for i in $(SRCDIRS); do etags -a $$i/*.[ch]; done
# Touch generated files
# This fixes up the mtimes of checked-in generated files, assuming that they
# only *appear* to be outdated because of checkout order.
# This is run while preparing a source release tarball, and can be run manually
# to avoid bootstrap issues.
touch:
cd $(srcdir); \
hg --config extensions.touch=Tools/hg/hgtouch.py touch -v