[Python-checkins] cpython (merge 3.4 -> default): merge with 3.4

[georg.brandl]

https://hg.python.org/cpython/rev/c6c7bd9874fb
changeset:   92849:c6c7bd9874fb
parent:      92846:b4075c8b53a7
parent:      92848:8c33440d1f64
user:        Georg Brandl <georg at python.org>
date:        Mon Oct 06 16:19:20 2014 +0200
summary:
  merge with 3.4

files:
  Doc/faq/programming.rst |  18 ++----------------
  Makefile.pre.in         |   8 ++++++--
  2 files changed, 8 insertions(+), 18 deletions(-)


diff --git a/Doc/faq/programming.rst b/Doc/faq/programming.rst
--- a/Doc/faq/programming.rst
+++ b/Doc/faq/programming.rst
@@ -292,9 +292,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.
@@ -308,11 +307,6 @@
    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 @@
 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
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -343,7 +343,8 @@
 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 @@
 	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

-- 
Repository URL: https://hg.python.org/cpython