diff options
| -rw-r--r-- | Doc/faq/programming.rst | 18 | ||||
| -rw-r--r-- | Makefile.pre.in | 8 |
2 files changed, 8 insertions, 18 deletions
diff --git a/Doc/faq/programming.rst b/Doc/faq/programming.rst index ffb7e8b..c30c2b6 100644 --- a/Doc/faq/programming.rst +++ b/Doc/faq/programming.rst @@ -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? ---------------------------------------------- diff --git a/Makefile.pre.in b/Makefile.pre.in index e5f5644..894b08e 100644 --- a/Makefile.pre.in +++ b/Makefile.pre.in @@ -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 |