summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--Grammar/Grammar2
-rw-r--r--Lib/idlelib/ChangeLog10
-rw-r--r--Lib/idlelib/HISTORY.txt8
-rw-r--r--Lib/idlelib/README.txt2
-rw-r--r--Lib/lib2to3/Grammar.txt2
-rw-r--r--Mac/BuildScript/README.txt16
-rw-r--r--Mac/README14
-rw-r--r--Misc/Porting2
-rw-r--r--Misc/gdbinit4
-rwxr-xr-xModules/makesetup2
-rw-r--r--PC/example_nt/readme.txt20
-rw-r--r--Tools/freeze/README18
-rw-r--r--Tools/pybench/README14
-rw-r--r--Tools/pynche/README14
-rw-r--r--Tools/unittestgui/README.txt4
15 files changed, 66 insertions, 66 deletions
diff --git a/Grammar/Grammar b/Grammar/Grammar
index 6c012c0..94898d3 100644
--- 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
index 985871b..90e02f6 100644
--- 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
index 01d73ed..731fabd 100644
--- 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
index b2bb73b..7f4a66d 100644
--- 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
index e667bcd..ce95d26 100644
--- 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
index 3ced066..46830ad 100644
--- 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
index 0a313d1..d9622a6 100644
--- 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
index 51f73e6..c283cb2 100644
--- 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
index 9484b51..3b6fe50 100644
--- 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
index 8b5cc28..90db42e 100755
--- 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
index b83888c..d8efa74 100644
--- 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
index 81be2c8..5bc5b04 100644
--- 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
index e59e6c0..40f7eec 100644
--- a/Tools/pybench/README
+++ b/Tools/pybench/README
@@ -4,7 +4,7 @@ PYBENCH - A Python Benchmark Suite
________________________________________________________________________
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 @@ to have it store the results in a file too.
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 @@ class IntegerCounting(Test):
# 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 @@ class IntegerCounting(Test):
# 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 @@ Version History
- 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
index d20efc3..e026159 100644
--- a/Tools/pynche/README
+++ b/Tools/pynche/README
@@ -48,7 +48,7 @@ Running Standalone
--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 @@ Running as a Modal Dialog
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 @@ Running as a Modal Dialog
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 @@ The Proof Window
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 @@ Color Name Database Files
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 @@ Color Name Database Files
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
index 4d809df..0a477e1 100644
--- 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: