[Python-checkins] cpython: Removed unintentional trailing spaces in text files.
serhiy.storchaka
python-checkins at python.org
Sun Mar 29 18:24:20 CEST 2015
https://hg.python.org/cpython/rev/d2ec09915beb
changeset: 95244:d2ec09915beb
user: Serhiy Storchaka <storchaka at gmail.com>
date: Sun Mar 29 19:12:58 2015 +0300
summary:
Removed unintentional trailing spaces in text files.
files:
Grammar/Grammar | 2 +-
Lib/idlelib/ChangeLog | 10 +++++-----
Lib/idlelib/HISTORY.txt | 8 ++++----
Lib/idlelib/README.txt | 2 +-
Lib/lib2to3/Grammar.txt | 2 +-
Mac/BuildScript/README.txt | 16 ++++++++--------
Mac/README | 14 +++++++-------
Misc/Porting | 2 +-
Misc/gdbinit | 4 ++--
Modules/makesetup | 2 +-
PC/example_nt/readme.txt | 20 ++++++++++----------
Tools/freeze/README | 18 +++++++++---------
Tools/pybench/README | 14 +++++++-------
Tools/pynche/README | 14 +++++++-------
Tools/unittestgui/README.txt | 4 ++--
15 files changed, 66 insertions(+), 66 deletions(-)
diff --git a/Grammar/Grammar b/Grammar/Grammar
--- a/Grammar/Grammar
+++ b/Grammar/Grammar
@@ -117,7 +117,7 @@
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
--- a/Lib/idlelib/ChangeLog
+++ b/Lib/idlelib/ChangeLog
@@ -20,7 +20,7 @@
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 @@
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 @@
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 @@
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
--- a/Lib/idlelib/HISTORY.txt
+++ b/Lib/idlelib/HISTORY.txt
@@ -11,7 +11,7 @@
*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 @@
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 @@
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
--- a/Lib/idlelib/README.txt
+++ b/Lib/idlelib/README.txt
@@ -14,7 +14,7 @@
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
--- a/Lib/lib2to3/Grammar.txt
+++ b/Lib/lib2to3/Grammar.txt
@@ -142,7 +142,7 @@
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
--- a/Mac/BuildScript/README.txt
+++ b/Mac/BuildScript/README.txt
@@ -2,10 +2,10 @@
=======================================
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 @@
/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 @@
- 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 @@
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 @@
/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
--- a/Mac/README
+++ b/Mac/README
@@ -19,7 +19,7 @@
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 @@
* ``--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 @@
--------------------------------------------------------------------------
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 @@
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 @@
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
--- a/Misc/Porting
+++ b/Misc/Porting
@@ -27,7 +27,7 @@
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
--- a/Misc/gdbinit
+++ b/Misc/gdbinit
@@ -150,10 +150,10 @@
# 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
--- a/Modules/makesetup
+++ b/Modules/makesetup
@@ -266,7 +266,7 @@
*) 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
--- a/PC/example_nt/readme.txt
+++ b/PC/example_nt/readme.txt
@@ -3,7 +3,7 @@
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 @@
% 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 @@
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 @@
(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 @@
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 @@
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
--- a/Tools/freeze/README
+++ b/Tools/freeze/README
@@ -100,8 +100,8 @@
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 @@
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 @@
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 @@
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 @@
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
--- a/Tools/pybench/README
+++ b/Tools/pybench/README
@@ -4,7 +4,7 @@
________________________________________________________________________
Extendable suite of low-level benchmarks for measuring
- the performance of the Python implementation
+ the performance of the Python implementation
(interpreter, compiler or VM).
pybench is a collection of tests that provides a standardized way to
@@ -34,11 +34,11 @@
It is usually a good idea to run pybench.py multiple times to see
whether the environment, timers and benchmark run-times are suitable
-for doing benchmark tests.
+for doing benchmark tests.
You can use the comparison feature of pybench.py ('pybench.py -c
<file>') to check how well the system behaves in comparison to a
-reference run.
+reference run.
If the differences are well below 10% for each test, then you have a
system that is good for doing benchmark testings. Of you get random
@@ -232,7 +232,7 @@
# for comparisons of benchmark runs - tests with unequal version
# number will not get compared.
version = 1.0
-
+
# The number of abstract operations done in each round of the
# test. An operation is the basic unit of what you want to
# measure. The benchmark will output the amount of run-time per
@@ -264,7 +264,7 @@
# Repeat the operations per round to raise the run-time
# per operation significantly above the noise level of the
- # for-loop overhead.
+ # for-loop overhead.
# Execute 20 operations (a += 1):
a += 1
@@ -358,8 +358,8 @@
- changed the output format a bit to make it look
nicer
- refactored the APIs somewhat
- 1.3+: Steve Holden added the NewInstances test and the filtering
- option during the NeedForSpeed sprint; this also triggered a long
+ 1.3+: Steve Holden added the NewInstances test and the filtering
+ option during the NeedForSpeed sprint; this also triggered a long
discussion on how to improve benchmark timing and finally
resulted in the release of 2.0
1.3: initial checkin into the Python SVN repository
diff --git a/Tools/pynche/README b/Tools/pynche/README
--- a/Tools/pynche/README
+++ b/Tools/pynche/README
@@ -48,7 +48,7 @@
--initfile file
-i file
- Alternate location of the persistent initialization file. See
+ Alternate location of the persistent initialization file. See
the section on Persistency below.
--ignore
@@ -80,7 +80,7 @@
pyColorChooser.askcolor()
- which will popup Pynche as a modal dialog, and return the selected
+ which will popup Pynche as a modal dialog, and return the selected
color.
There are some UI differences when running as a modal
@@ -106,7 +106,7 @@
master[*]
the master window to use as the parent of the modal
- dialog. Without this argument, pyColorChooser will create
+ dialog. Without this argument, pyColorChooser will create
its own Tkinter.Tk instance as the master. This may not
be what you want.
@@ -170,7 +170,7 @@
Selected chip color exactly matches the Nearest chip color, you
will see the color name appear below the color specification for
the Selected chip.
-
+
Clicking on the Nearest color chip selects that color. Color
distance is calculated in the 3D space of the RGB color solid and
if more than one color name is the same distance from the selected
@@ -361,7 +361,7 @@
format for both values and names
webcolors.txt -- The 140 color names that Tim Peters and his
- sister say NS and MSIE both understand (with some controversy over
+ sister say NS and MSIE both understand (with some controversy over
AliceBlue).
namedcolors.txt -- an alternative set of Netscape colors.
@@ -369,8 +369,8 @@
You can switch between files by choosing "Load palette..." from
the "File" menu. This brings up a standard Tk file dialog.
Choose the file you want and then click "Ok". If Pynche
- understands the format in this file, it will load the database and
- update the appropriate windows. If not, it will bring up an error
+ understands the format in this file, it will load the database and
+ update the appropriate windows. If not, it will bring up an error
dialog.
diff --git a/Tools/unittestgui/README.txt b/Tools/unittestgui/README.txt
--- a/Tools/unittestgui/README.txt
+++ b/Tools/unittestgui/README.txt
@@ -1,5 +1,5 @@
-unittestgui.py is GUI framework and application for use with Python unit
-testing framework. It executes tests written using the framework provided
+unittestgui.py is GUI framework and application for use with Python unit
+testing framework. It executes tests written using the framework provided
by the 'unittest' module.
Based on the original by Steve Purcell, from:
--
Repository URL: https://hg.python.org/cpython
More information about the Python-checkins
mailing list