diff options
| -rw-r--r-- | Grammar/Grammar | 2 | ||||
| -rw-r--r-- | Lib/idlelib/ChangeLog | 10 | ||||
| -rw-r--r-- | Lib/idlelib/HISTORY.txt | 8 | ||||
| -rw-r--r-- | Lib/idlelib/README.txt | 2 | ||||
| -rw-r--r-- | Lib/lib2to3/Grammar.txt | 2 | ||||
| -rw-r--r-- | Mac/BuildScript/README.txt | 16 | ||||
| -rw-r--r-- | Mac/README | 14 | ||||
| -rw-r--r-- | Misc/Porting | 2 | ||||
| -rw-r--r-- | Misc/gdbinit | 4 | ||||
| -rwxr-xr-x | Modules/makesetup | 2 | ||||
| -rw-r--r-- | PC/example_nt/readme.txt | 20 | ||||
| -rw-r--r-- | Tools/freeze/README | 18 | ||||
| -rw-r--r-- | Tools/pybench/README | 14 | ||||
| -rw-r--r-- | Tools/pynche/README | 14 | ||||
| -rw-r--r-- | Tools/unittestgui/README.txt | 4 |
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 @@ -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: |