mirror of
https://github.com/python/cpython.git
synced 2025-11-25 04:34:37 +00:00
Merged revisions 84945 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/py3k ........ r84945 | georg.brandl | 2010-09-21 16:48:28 +0200 (Di, 21 Sep 2010) | 1 line #9911: doc copyedits. ........
This commit is contained in:
parent
21946afe3f
commit
0930228aee
18 changed files with 21 additions and 21 deletions
|
|
@ -358,7 +358,7 @@ would create a 64bit installation executable on your 32bit version of Windows.
|
|||
|
||||
To cross-compile, you must download the Python source code and cross-compile
|
||||
Python itself for the platform you are targetting - it is not possible from a
|
||||
binary installtion of Python (as the .lib etc file for other platforms are
|
||||
binary installation of Python (as the .lib etc file for other platforms are
|
||||
not included.) In practice, this means the user of a 32 bit operating
|
||||
system will need to use Visual Studio 2008 to open the
|
||||
:file:`PCBuild/PCbuild.sln` solution in the Python source tree and build the
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ coding-style conflicts. In C there are many different ways to place the braces.
|
|||
If you're used to reading and writing code that uses one style, you will feel at
|
||||
least slightly uneasy when reading (or being required to write) another style.
|
||||
|
||||
Many coding styles place begin/end brackets on a line by themself. This makes
|
||||
Many coding styles place begin/end brackets on a line by themselves. This makes
|
||||
programs considerably longer and wastes valuable screen space, making it harder
|
||||
to get a good overview of a program. Ideally, a function should fit on one
|
||||
screen (say, 20-30 lines). 20 lines of Python can do a lot more work than 20
|
||||
|
|
|
|||
|
|
@ -944,7 +944,7 @@ Is there an equivalent to Perl's chomp() for removing trailing newlines from str
|
|||
-------------------------------------------------------------------------------------
|
||||
|
||||
Starting with Python 2.2, you can use ``S.rstrip("\r\n")`` to remove all
|
||||
occurences of any line terminator from the end of the string ``S`` without
|
||||
occurrences of any line terminator from the end of the string ``S`` without
|
||||
removing other trailing whitespace. If the string ``S`` represents more than
|
||||
one line, with several empty lines at the end, the line terminators for all the
|
||||
blank lines will be removed::
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Glossary
|
|||
|
||||
2to3
|
||||
A tool that tries to convert Python 2.x code to Python 3.x code by
|
||||
handling most of the incompatibilites which can be detected by parsing the
|
||||
handling most of the incompatibilities which can be detected by parsing the
|
||||
source and traversing the parse tree.
|
||||
|
||||
2to3 is available in the standard library as :mod:`lib2to3`; a standalone
|
||||
|
|
|
|||
|
|
@ -296,7 +296,7 @@ Running the interpreter shows how the function descriptor works in practice::
|
|||
<bound method D.f of <__main__.D object at 0x00B18C90>>
|
||||
|
||||
The output suggests that bound and unbound methods are two different types.
|
||||
While they could have been implemented that way, the actual C implemention of
|
||||
While they could have been implemented that way, the actual C implementation of
|
||||
:ctype:`PyMethod_Type` in
|
||||
`Objects/classobject.c <http://svn.python.org/view/python/trunk/Objects/classobject.c?view=markup>`_
|
||||
is a single object with two different representations depending on whether the
|
||||
|
|
|
|||
|
|
@ -314,7 +314,7 @@ process is likely to be screwed up.
|
|||
Non-blocking Sockets
|
||||
====================
|
||||
|
||||
If you've understood the preceeding, you already know most of what you need to
|
||||
If you've understood the preceding, you already know most of what you need to
|
||||
know about the mechanics of using sockets. You'll still use the same calls, in
|
||||
much the same ways. It's just that, if you do it right, your app will be almost
|
||||
inside-out.
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ process.
|
|||
Since some print statements can be parsed as function calls or statements, 2to3
|
||||
cannot always read files containing the print function. When 2to3 detects the
|
||||
presence of the ``from __future__ import print_function`` compiler directive, it
|
||||
modifies its internal grammar to interpert :func:`print` as a function. This
|
||||
modifies its internal grammar to interpret :func:`print` as a function. This
|
||||
change can also be enabled manually with the :option:`-p` flag. Use
|
||||
:option:`-p` to run fixers on code that already has had its print statements
|
||||
converted.
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ a 'B', and so on::
|
|||
|
||||
Unlike the :func:`sorted` function, it does not make sense for the :func:`bisect`
|
||||
functions to have *key* or *reversed* arguments because that would lead to an
|
||||
inefficent design (successive calls to bisect functions would not "remember"
|
||||
inefficient design (successive calls to bisect functions would not "remember"
|
||||
all of the previous key lookups).
|
||||
|
||||
Instead, it is better to search a list of precomputed keys to find the index
|
||||
|
|
|
|||
|
|
@ -23,5 +23,5 @@ help ease in transitioning from 2.7 to 3.1.
|
|||
specified in relative terms, then the *package* argument must be
|
||||
specified to the package which is to act as the anchor for resolving the
|
||||
package name (e.g. ``import_module('..mod', 'pkg.subpkg')`` will import
|
||||
``pkg.mod``). The specified module will be inserted into
|
||||
``pkg.mod``). The specified module will be inserted into
|
||||
:data:`sys.modules` and returned.
|
||||
|
|
|
|||
|
|
@ -2744,7 +2744,7 @@ wire).
|
|||
.. attribute:: exc_info
|
||||
|
||||
Exception tuple (à la `sys.exc_info`) or `None` if no exception
|
||||
information is availble.
|
||||
information is available.
|
||||
|
||||
.. attribute:: func
|
||||
|
||||
|
|
|
|||
|
|
@ -376,7 +376,7 @@ The :mod:`multiprocessing` package mostly replicates the API of the
|
|||
Otherwise a daemonic process would leave its children orphaned if it gets
|
||||
terminated when its parent process exits. Additionally, these are **not**
|
||||
Unix daemons or services, they are normal processes that will be
|
||||
terminated (and not joined) if non-dameonic processes have exited.
|
||||
terminated (and not joined) if non-daemonic processes have exited.
|
||||
|
||||
In addition to the :class:`Threading.Thread` API, :class:`Process` objects
|
||||
also support the following attributes and methods:
|
||||
|
|
|
|||
|
|
@ -337,7 +337,7 @@ process and user.
|
|||
|
||||
Set the current process's real, effective, and saved user ids.
|
||||
|
||||
Availibility: Unix.
|
||||
Availability: Unix.
|
||||
|
||||
.. versionadded:: 2.7
|
||||
|
||||
|
|
|
|||
|
|
@ -620,7 +620,7 @@ The resulting profiler will then call :func:`your_time_func`.
|
|||
integers, you can also invoke the class constructor with a second argument
|
||||
specifying the real duration of one unit of time. For example, if
|
||||
:func:`your_integer_time_func` returns times measured in thousands of seconds,
|
||||
you would constuct the :class:`Profile` instance as follows::
|
||||
you would construct the :class:`Profile` instance as follows::
|
||||
|
||||
pr = profile.Profile(your_integer_time_func, 0.001)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ interactive prompt and the prompts offered by the :func:`raw_input` and
|
|||
the ``libedit`` library instead of GNU readline.
|
||||
|
||||
The configuration file for ``libedit`` is different from that
|
||||
of GNU readline. If you programmaticly load configuration strings
|
||||
of GNU readline. If you programmatically load configuration strings
|
||||
you can check for the text "libedit" in :const:`readline.__doc__`
|
||||
to differentiate between GNU readline and libedit.
|
||||
|
||||
|
|
|
|||
|
|
@ -198,8 +198,8 @@ Telnet Objects
|
|||
received so far (may be the empty string if a timeout happened).
|
||||
|
||||
If a regular expression ends with a greedy match (such as ``.*``) or if more
|
||||
than one expression can match the same input, the results are indeterministic,
|
||||
and may depend on the I/O timing.
|
||||
than one expression can match the same input, the results are
|
||||
non-deterministic, and may depend on the I/O timing.
|
||||
|
||||
|
||||
.. method:: Telnet.set_option_negotiation_callback(callback)
|
||||
|
|
|
|||
|
|
@ -1835,7 +1835,7 @@ Methods specific to Screen, not inherited from TurtleScreen
|
|||
.. function:: setup(width=_CFG["width"], height=_CFG["height"], startx=_CFG["leftright"], starty=_CFG["topbottom"])
|
||||
|
||||
Set the size and position of the main window. Default values of arguments
|
||||
are stored in the configuration dicionary and can be changed via a
|
||||
are stored in the configuration dictionary and can be changed via a
|
||||
:file:`turtle.cfg` file.
|
||||
|
||||
:param width: if an integer, a size in pixels, if a float, a fraction of the
|
||||
|
|
|
|||
|
|
@ -634,7 +634,7 @@ The following decorators implement test skipping and expected failures:
|
|||
|
||||
.. function:: skipUnless(condition, reason)
|
||||
|
||||
Skip the decoratored test unless *condition* is true.
|
||||
Skip the decorated test unless *condition* is true.
|
||||
|
||||
.. function:: expectedFailure
|
||||
|
||||
|
|
@ -1523,8 +1523,8 @@ Loading and running tests
|
|||
|
||||
.. attribute:: expectedFailures
|
||||
|
||||
A list contaning 2-tuples of :class:`TestCase` instances and strings
|
||||
holding formatted tracebacks. Each tuple represents a expected failures
|
||||
A list containing 2-tuples of :class:`TestCase` instances and strings
|
||||
holding formatted tracebacks. Each tuple represents an expected failure
|
||||
of the test case.
|
||||
|
||||
.. attribute:: unexpectedSuccesses
|
||||
|
|
|
|||
|
|
@ -417,7 +417,7 @@ All of this makes generator functions quite similar to coroutines; they yield
|
|||
multiple times, they have more than one entry point and their execution can be
|
||||
suspended. The only difference is that a generator function cannot control
|
||||
where should the execution continue after it yields; the control is always
|
||||
transfered to the generator's caller.
|
||||
transferred to the generator's caller.
|
||||
|
||||
.. index:: object: generator
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue