Removed unintentional trailing spaces in text files.

serhiy-storchaka · serhiy-storchaka · commit bfbfc8deb2b1 · 2015-03-29T19:12:58.000+03:00
diff --git a/Grammar/Grammar b/Grammar/Grammar
@@ -117,7 +117,7 @@ dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [','])) |
 classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
 
 arglist: (argument ',')* (argument [',']
-                         |'*' test (',' argument)* [',' '**' test] 
+                         |'*' test (',' argument)* [',' '**' test]
                          |'**' test)
 # The reason that keywords are test nodes instead of NAME is that using NAME
 # results in an ambiguity. ast.c makes sure it's a NAME.
diff --git a/Lib/idlelib/ChangeLog b/Lib/idlelib/ChangeLog
@@ -20,7 +20,7 @@ IDLEfork ChangeLog
 2001-07-19 14:49  elguavas
 
 	* ChangeLog, EditorWindow.py, INSTALLATION, NEWS.txt, README.txt,
-	TODO.txt, idlever.py: 
+	TODO.txt, idlever.py:
 	minor tidy-ups ready for 0.8.1 alpha tarball release
 
 2001-07-17 15:12  kbk
@@ -172,7 +172,7 @@ IDLEfork ChangeLog
 	all this work w/ a future-stmt just looks harder and harder."
 	--tim_one
 	
-	(From Rel 1.8: "Hack to make this still work with Python 1.5.2. 
+	(From Rel 1.8: "Hack to make this still work with Python 1.5.2.
 	;-( " --fdrake)
 
 2001-07-14 14:51  kbk
@@ -193,7 +193,7 @@ IDLEfork ChangeLog
 	test() to _test()."  --GvR
 	
 	This was an interesting merge. The join completely missed removing
-	goodname(), which was adjacent, but outside of, a small conflict. 
+	goodname(), which was adjacent, but outside of, a small conflict.
 	I only caught it by comparing the 1.1.3.2/1.1.3.3 diff.  CVS ain't
 	infallible.
 
@@ -516,12 +516,12 @@ IDLEfork ChangeLog
 
 2000-08-15 22:51  nowonder
 
-	* IDLEFORK.html: 
+	* IDLEFORK.html:
 	corrected email address
 
 2000-08-15 22:47  nowonder
 
-	* IDLEFORK.html: 
+	* IDLEFORK.html:
 	added .html file for http://idlefork.sourceforge.net
 
 2000-08-15 11:13  dscherer
diff --git a/Lib/idlelib/HISTORY.txt b/Lib/idlelib/HISTORY.txt
@@ -11,7 +11,7 @@ What's New in IDLEfork 0.8.1?
 *Release date: 22-Jul-2001*
 
 - New tarball released as a result of the 'revitalisation' of the IDLEfork
-  project. 
+  project.
 
 - This release requires python 2.1 or better. Compatibility with earlier
   versions of python (especially ancient ones like 1.5x) is no longer a
@@ -26,8 +26,8 @@ What's New in IDLEfork 0.8.1?
   not working, but I believe this was the case with the previous IDLE fork
   release (0.7.1) as well.
 
-- This release is being made now to mark the point at which IDLEfork is 
-  launching into a new stage of development. 
+- This release is being made now to mark the point at which IDLEfork is
+  launching into a new stage of development.
 
 - IDLEfork CVS will now be branched to enable further development and
   exploration of the two "execution in a remote process" patches submitted by
@@ -96,7 +96,7 @@ IDLEfork 0.7.1 - 29 May 2000
     instead of the IDLE help; shift-TAB is now a synonym for unindent.
 
 - New modules:
-  
+
   ExecBinding.py         Executes program through loader
   loader.py              Bootstraps user program
   protocol.py            RPC protocol
diff --git a/Lib/idlelib/README.txt b/Lib/idlelib/README.txt
@@ -14,7 +14,7 @@ code objects from a top level viewpoint without dealing with code folding.
 There is a Python Shell window which features colorizing and command recall.
 
 IDLE executes Python code in a separate process, which is restarted for each
-Run (F5) initiated from an editor window.  The environment can also be 
+Run (F5) initiated from an editor window.  The environment can also be
 restarted from the Shell window without restarting IDLE.
 
 This enhancement has often been requested, and is now finally available.  The
diff --git a/Lib/lib2to3/Grammar.txt b/Lib/lib2to3/Grammar.txt
@@ -142,7 +142,7 @@ dictsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [','])) |
 classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
 
 arglist: (argument ',')* (argument [',']
-                         |'*' test (',' argument)* [',' '**' test] 
+                         |'*' test (',' argument)* [',' '**' test]
                          |'**' test)
 argument: test [comp_for] | test '=' test  # Really [keyword '='] test
 
diff --git a/Mac/BuildScript/README.txt b/Mac/BuildScript/README.txt
@@ -2,10 +2,10 @@ Building a Python Mac OS X distribution
 =======================================
 
 The ``build-install.py`` script creates Python distributions, including
-certain third-party libraries as necessary.  It builds a complete 
-framework-based Python out-of-tree, installs it in a funny place with 
-$DESTROOT, massages that installation to remove .pyc files and such, creates 
-an Installer package from the installation plus other files in ``resources`` 
+certain third-party libraries as necessary.  It builds a complete
+framework-based Python out-of-tree, installs it in a funny place with
+$DESTROOT, massages that installation to remove .pyc files and such, creates
+an Installer package from the installation plus other files in ``resources``
 and ``scripts`` and placed that on a ``.dmg`` disk image.
 
 For Python 3.4.0, PSF practice is to build two installer variants
@@ -101,7 +101,7 @@ for each release.
         /usr/bin/python build-installer.py \
             --sdk-path=/Developer/SDKs/MacOSX10.4u.sdk \
             --universal-archs=32-bit \
-            --dep-target=10.3 
+            --dep-target=10.3
 
     - builds the following third-party libraries
 
@@ -116,7 +116,7 @@ for each release.
     - requires ActiveState ``Tcl/Tk 8.4`` (currently 8.4.20) to be installed for building
 
     - recommended build environment:
-        
+
         * Mac OS X 10.5.8 PPC or Intel
         * Xcode 3.1.4 (or later)
         * ``MacOSX10.4u`` SDK (later SDKs do not support PPC G3 processors)
@@ -174,7 +174,7 @@ Here are the steps you need to follow to build a Python installer:
 Building other universal installers
 ...................................
 
-It is also possible to build a 4-way universal installer that runs on 
+It is also possible to build a 4-way universal installer that runs on
 OS X 10.5 Leopard or later::
 
     /usr/bin/python /build-installer.py \
@@ -208,7 +208,7 @@ a PPC G4 system with OS X 10.5 and at least one Intel system running OS X
 
     /usr/local/bin/pythonn.n -m test -w -u all,-largefile
     /usr/local/bin/pythonn.n-32 -m test -w -u all
-    
+
 Certain tests will be skipped and some cause the interpreter to fail
 which will likely generate ``Python quit unexpectedly`` alert messages
 to be generated at several points during a test run.  These are normal
diff --git a/Mac/README b/Mac/README
@@ -19,7 +19,7 @@ OS X specific arguments to configure
 
   If this argument is specified the build will create a Python.framework rather
   than a traditional Unix install. See the section
-  _`Building and using a framework-based Python on Mac OS X` for more 
+  _`Building and using a framework-based Python on Mac OS X` for more
   information on frameworks.
 
   If the optional directory argument is specified the framework is installed
@@ -53,7 +53,7 @@ OS X specific arguments to configure
 
 * ``--with-univeral-archs=VALUE``
 
-  Specify the kind of universal binary that should be created. This option is 
+  Specify the kind of universal binary that should be created. This option is
   only valid when ``--enable-universalsdk`` is specified.  The default is
   ``32-bit`` if a building with a SDK that supports PPC, otherwise defaults
   to ``intel``.
@@ -174,14 +174,14 @@ Building and using a framework-based Python on Mac OS X.
 --------------------------------------------------------------------------
 
 The main reason is because you want to create GUI programs in Python. With the
-exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run 
+exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run
 from a Mac OS X application bundle (".app").
 
 While it is technically possible to create a .app without using frameworks you
 will have to do the work yourself if you really want this.
 
 A second reason for using frameworks is that they put Python-related items in
-only two places: "/Library/Framework/Python.framework" and 
+only two places: "/Library/Framework/Python.framework" and
 "/Applications/Python <VERSION>" where ``<VERSION>`` can be e.g. "3.4",
 "2.7", etc.  This simplifies matters for users installing
 Python from a binary distribution if they want to get rid of it again. Moreover,
@@ -228,11 +228,11 @@ in the sequence
  1. ./configure --enable-framework
 
  2. make
- 
+
  3. make install
 
 This sequence will put the framework in ``/Library/Framework/Python.framework``,
-the applications in ``/Applications/Python <VERSION>`` and the unix tools in 
+the applications in ``/Applications/Python <VERSION>`` and the unix tools in
 ``/usr/local/bin``.
 
 Installing in another place, for instance ``$HOME/Library/Frameworks`` if you
@@ -300,7 +300,7 @@ All of this is normally done completely isolated in /tmp/_py, so it does not
 use your normal build directory nor does it install into /.
 
 Because of the way the script locates the files it needs you have to run it
-from within the BuildScript directory. The script accepts a number of 
+from within the BuildScript directory. The script accepts a number of
 command-line arguments, run it with --help for more information.
 
 Configure warnings
diff --git a/Misc/Porting b/Misc/Porting
@@ -27,7 +27,7 @@ And you'll need a config.c file, which lists the built-in modules you
 support.  Start with Modules/config.c.in.
 
 Finally, you'll run into some things that aren't supported on your
-target platform.  Forget about the posix module for now -- simply take 
+target platform.  Forget about the posix module for now -- simply take
 it out of the config.c file.
 
 Bang on it until you get a >>> prompt.  (You may have to disable the
diff --git a/Misc/gdbinit b/Misc/gdbinit
@@ -150,10 +150,10 @@ end
 
 # generally useful macro to print a Unicode string
 def pu
-  set $uni = $arg0 
+  set $uni = $arg0
   set $i = 0
   while (*$uni && $i++<100)
-    if (*$uni < 0x80) 
+    if (*$uni < 0x80)
       print *(char*)$uni++
     else
       print /x *(short*)$uni++
diff --git a/Modules/makesetup b/Modules/makesetup
@@ -266,7 +266,7 @@ sed -e 's/[ 	]*#.*//' -e '/^[ 	]*$/d' |
 	*)  sed -e "
 		1i$NL/* Generated automatically from $config by makesetup. */
 		/MARKER 1/i$NL$EXTDECLS
- 
+
 		/MARKER 2/i$NL$INITBITS
 
 		" $config >config.c
diff --git a/PC/example_nt/readme.txt b/PC/example_nt/readme.txt
@@ -3,7 +3,7 @@ Example Python extension for Windows NT
 
 This directory contains everything needed (except for the Python
 distribution!) to build a Python extension module using Microsoft VC++.
-Notice that you need to use the same compiler version that was used to build 
+Notice that you need to use the same compiler version that was used to build
 Python itself.
 
 The simplest way to build this example is to use the distutils script
@@ -16,7 +16,7 @@ after everything builds and installs, you can test it:
   % python -c "import example; example.foo()"
   Hello, world
 
-See setup.py for more details.  alternatively, see below for instructions on 
+See setup.py for more details.  alternatively, see below for instructions on
 how to build inside the Visual Studio environment.
 
 Visual Studio Build Instructions
@@ -27,8 +27,8 @@ instructions and project files have not been updated to the latest VC
 version.  In general, it is recommended you use the 'setup.py' instructions
 above.
 
-It has been tested with VC++ 7.1 on Python 2.4.  You can also use earlier 
-versions of VC to build Python extensions, but the sample VC project file 
+It has been tested with VC++ 7.1 on Python 2.4.  You can also use earlier
+versions of VC to build Python extensions, but the sample VC project file
 (example.dsw in this directory) is in VC 7.1 format.
 
 COPY THIS DIRECTORY!
@@ -129,7 +129,7 @@ created a new project yourself, add the file spam.def to the project now.
 (This is an annoying little file with only two lines.  An alternative
 approach is to forget about the .def file, and add the option
 "/export:initspam" somewhere to the Link settings, by manually editing the
-"Project -> Properties -> Linker -> Command Line -> Additional Options" 
+"Project -> Properties -> Linker -> Command Line -> Additional Options"
 box).
 
 You are now all set to build your extension, unless it requires other
@@ -142,13 +142,13 @@ CREATING A BRAND NEW PROJECT
 Use the
     File -> New -> Project...
 dialog to create a new Project Workspace.  Select "Visual C++ Projects/Win32/
-Win32 Project", enter the name ("spam"), and make sure the "Location" is 
-set to parent of the spam directory you have created (which should be a direct 
-subdirectory of the Python build tree, a sibling of Include and PC).  
+Win32 Project", enter the name ("spam"), and make sure the "Location" is
+set to parent of the spam directory you have created (which should be a direct
+subdirectory of the Python build tree, a sibling of Include and PC).
 In "Application Settings", select "DLL", and "Empty Project".  Click OK.
 
 You should now create the file spam.def as instructed in the previous
-section. Add the source files (including the .def file) to the project, 
+section. Add the source files (including the .def file) to the project,
 using "Project", "Add Existing Item".
 
 Now open the
@@ -174,7 +174,7 @@ list in the "Additional Dependencies" box.
 
 Select "Debug" in the "Settings for:" dropdown list, and append
 "python24_d.lib" to the list in the Additional Dependencies" box.  Then
-click on the C/C++ tab, select "Code Generation", and select 
+click on the C/C++ tab, select "Code Generation", and select
 "Multi-threaded Debug DLL" from the "Runtime library" dropdown list.
 
 Select "Release" again from the "Settings for:" dropdown list.
diff --git a/Tools/freeze/README b/Tools/freeze/README
@@ -100,8 +100,8 @@ to place the Tcl and Tk library files in the distributed setup, and
 then declare these directories in your frozen Python program using
 the TCL_LIBRARY, TK_LIBRARY and TIX_LIBRARY environment variables.
 
-For example, assume you will ship your frozen program in the directory 
-<root>/bin/windows-x86 and will place your Tcl library files 
+For example, assume you will ship your frozen program in the directory
+<root>/bin/windows-x86 and will place your Tcl library files
 in <root>/lib/tcl8.2 and your Tk library files in <root>/lib/tk8.2. Then
 placing the following lines in your frozen Python script before importing
 Tkinter or Tix would set the environment correctly for Tcl/Tk/Tix:
@@ -138,8 +138,8 @@ variable PATH is consulted, and under Unix, it may be the
 environment variable LD_LIBRARY_PATH and/or the system
 shared library cache (ld.so). An additional preferred directory for
 finding the dynamic libraries is built into the .dll or .so files at
-compile time - see the LIB_RUNTIME_DIR variable in the Tcl makefile. 
-The OS must find the dynamic libraries or your frozen program won't start. 
+compile time - see the LIB_RUNTIME_DIR variable in the Tcl makefile.
+The OS must find the dynamic libraries or your frozen program won't start.
 Usually I make sure that the .so or .dll files are in the same directory
 as the executable, but this may not be foolproof.
 
@@ -149,8 +149,8 @@ incorporated in a frozen Python module as string literals and written
 to a temporary location when the program runs; this is currently left
 as an exercise for the reader.  An easier approach is to freeze the
 Tcl/Tk/Tix code into the dynamic libraries using the Tcl ET code,
-or the Tix Stand-Alone-Module code. Of course, you can also simply 
-require that Tcl/Tk is required on the target installation, but be 
+or the Tix Stand-Alone-Module code. Of course, you can also simply
+require that Tcl/Tk is required on the target installation, but be
 careful that the version corresponds.
 
 There are some caveats using frozen Tkinter applications:
@@ -164,7 +164,7 @@ program was frozen, not where it is run from.
 A warning about shared library modules
 --------------------------------------
 
-When your Python installation uses shared library modules such as 
+When your Python installation uses shared library modules such as
 _tkinter.pyd, these will not be incorporated in the frozen program.
  Again, the frozen program will work when you test it, but it won't
  work when you ship it to a site without a Python installation.
@@ -275,9 +275,9 @@ Options:
               are read and the -i option replaced with the parsed
               params (note - quoting args in this file is NOT supported)
 
--s subsystem: Specify the subsystem (For Windows only.); 
+-s subsystem: Specify the subsystem (For Windows only.);
               'console' (default), 'windows', 'service' or 'com_dll'
-              
+
 -w:           Toggle Windows (NT or 95) behavior.
               (For debugging only -- on a win32 platform, win32 behavior
               is automatic.)
diff --git a/Tools/pybench/README b/Tools/pybench/README
diff --git a/Tools/pynche/README b/Tools/pynche/README
diff --git a/Tools/unittestgui/README.txt b/Tools/unittestgui/README.txt
