mirror of
https://github.com/python/cpython.git
synced 2025-09-24 09:23:02 +00:00
Issue #5341: Fix a variety of spelling errors.
This commit is contained in:
parent
a12a86e956
commit
3e4caeb3bf
56 changed files with 93 additions and 93 deletions
|
@ -426,7 +426,7 @@ MVC stands for three components:
|
|||
user. Typically this component is represented by the templates.
|
||||
* The *controller*. This is the layer between the user and the model. The
|
||||
controller reacts on user actions (like opening some specific URL) and tells
|
||||
the model to modify the data if neccessary.
|
||||
the model to modify the data if necessary.
|
||||
|
||||
While one might think that MVC is a complex design pattern, in fact it is not.
|
||||
It is used in Python because it has turned out to be useful for creating clean,
|
||||
|
@ -435,9 +435,9 @@ maintainable web sites.
|
|||
.. note::
|
||||
|
||||
While not all Python frameworks explicitly support MVC, it is often trivial
|
||||
to create a web site which uses the MVC pattern by seperating the data logic
|
||||
to create a web site which uses the MVC pattern by separating the data logic
|
||||
(the model) from the user interaction logic (the controller) and the
|
||||
templates (the view). That's why it is important not to write unneccessary
|
||||
templates (the view). That's why it is important not to write unnecessary
|
||||
Python code in the templates -- it is against MVC and creates more chaos.
|
||||
|
||||
.. seealso::
|
||||
|
@ -607,7 +607,7 @@ Some notable frameworks
|
|||
-----------------------
|
||||
|
||||
There is an incredible number of frameworks, so there is no way to describe them
|
||||
all. It is not even neccessary, as most of these frameworks are nothing special
|
||||
all. It is not even necessary, as most of these frameworks are nothing special
|
||||
and everything that can be done with these can also be done with one of the
|
||||
popular ones.
|
||||
|
||||
|
@ -679,7 +679,7 @@ project called `Grok <http://grok.zope.org/>`_ which makes it possible for
|
|||
Another framework that's already been mentioned is `Pylons`_. Pylons is much
|
||||
like TurboGears with ab even stronger emphasis on flexibility, which is bought
|
||||
at the cost of being more difficult to use. Nearly every component can be
|
||||
exchanged, which makes it neccessary to use the documentation of every single
|
||||
exchanged, which makes it necessary to use the documentation of every single
|
||||
component, because there are so many Pylons combinations possible that can
|
||||
satisfy every requirement. Pylons builds upon `Paste
|
||||
<http://pythonpaste.org/>`_, an extensive set of tools which are handy for WSGI.
|
||||
|
|
|
@ -14,7 +14,7 @@ builtin :func:`open` function is defined in this module.
|
|||
|
||||
At the top of the I/O hierarchy is the abstract base class :class:`IOBase`. It
|
||||
defines the basic interface to a stream. Note, however, that there is no
|
||||
seperation between reading and writing to streams; implementations are allowed
|
||||
separation between reading and writing to streams; implementations are allowed
|
||||
to throw an :exc:`IOError` if they do not support a given operation.
|
||||
|
||||
Extending :class:`IOBase` is :class:`RawIOBase` which deals simply with the
|
||||
|
@ -612,7 +612,7 @@ Text I/O
|
|||
is enabled. With this enabled, on input, the lines endings ``'\n'``,
|
||||
``'\r'``, or ``'\r\n'`` are translated to ``'\n'`` before being returned to
|
||||
the caller. Conversely, on output, ``'\n'`` is translated to the system
|
||||
default line seperator, :data:`os.linesep`. If *newline* is any other of its
|
||||
default line separator, :data:`os.linesep`. If *newline* is any other of its
|
||||
legal values, that newline becomes the newline when the file is read and it
|
||||
is returned untranslated. On output, ``'\n'`` is converted to the *newline*.
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ The :mod:`pty` module defines operations for handling the pseudo-terminal
|
|||
concept: starting another process and being able to write to and read from its
|
||||
controlling terminal programmatically.
|
||||
|
||||
Because pseudo-terminal handling is highly platform dependant, there is code to
|
||||
Because pseudo-terminal handling is highly platform dependent, there is code to
|
||||
do it only for SGI and Linux. (The Linux code is supposed to work on other
|
||||
platforms, but hasn't been tested yet.)
|
||||
|
||||
|
|
|
@ -181,9 +181,9 @@ This module also defines two shortcut functions:
|
|||
To capture standard error in the result, use stderr=subprocess.STDOUT.
|
||||
|
||||
>>> subprocess.check_output(
|
||||
["/bin/sh", "-c", "ls non_existant_file ; exit 0"],
|
||||
["/bin/sh", "-c", "ls non_existent_file ; exit 0"],
|
||||
stderr=subprocess.STDOUT)
|
||||
'ls: non_existant_file: No such file or directory\n'
|
||||
'ls: non_existent_file: No such file or directory\n'
|
||||
|
||||
.. versionadded:: 2.7
|
||||
|
||||
|
|
|
@ -470,7 +470,7 @@ arguments)``. This is occasionally useful to clients as well. (Note that this
|
|||
only works if the base class is defined or imported directly in the global
|
||||
scope.)
|
||||
|
||||
Python has two builtin functions that work with inheritance:
|
||||
Python has two built-in functions that work with inheritance:
|
||||
|
||||
* Use :func:`isinstance` to check an object's type: ``isinstance(obj, int)``
|
||||
will be ``True`` only if ``obj.__class__`` is :class:`int` or some class
|
||||
|
|
|
@ -308,7 +308,7 @@ A more verbose version of this snippet shows the flow explicitly::
|
|||
print row[i],
|
||||
print
|
||||
|
||||
In real world, you should prefer builtin functions to complex flow statements.
|
||||
In real world, you should prefer built-in functions to complex flow statements.
|
||||
The :func:`zip` function would do a great job for this use case::
|
||||
|
||||
>>> zip(*mat)
|
||||
|
|
|
@ -65,7 +65,7 @@ display ::
|
|||
>>> 0.1
|
||||
0.1000000000000000055511151231257827021181583404541015625
|
||||
|
||||
instead! The Python prompt uses the builtin :func:`repr` function to obtain a
|
||||
instead! The Python prompt uses the built-in :func:`repr` function to obtain a
|
||||
string version of everything it displays. For floats, ``repr(float)`` rounds
|
||||
the true decimal value to 17 significant digits, giving ::
|
||||
|
||||
|
@ -81,7 +81,7 @@ thing in all languages that support your hardware's floating-point arithmetic
|
|||
(although some languages may not *display* the difference by default, or in all
|
||||
output modes).
|
||||
|
||||
Python's builtin :func:`str` function produces only 12 significant digits, and
|
||||
Python's built-in :func:`str` function produces only 12 significant digits, and
|
||||
you may wish to use that instead. It's unusual for ``eval(str(x))`` to
|
||||
reproduce *x*, but the output may be more pleasant to look at::
|
||||
|
||||
|
|
|
@ -187,7 +187,7 @@ notation.::
|
|||
This is particularly useful in combination with the new built-in :func:`vars`
|
||||
function, which returns a dictionary containing all local variables.
|
||||
|
||||
For a complete overview of string formating with :meth:`str.format`, see
|
||||
For a complete overview of string formatting with :meth:`str.format`, see
|
||||
:ref:`formatstrings`.
|
||||
|
||||
|
||||
|
|
|
@ -21,12 +21,12 @@ operating system::
|
|||
>>> os.chdir('/server/accesslogs')
|
||||
|
||||
Be sure to use the ``import os`` style instead of ``from os import *``. This
|
||||
will keep :func:`os.open` from shadowing the builtin :func:`open` function which
|
||||
will keep :func:`os.open` from shadowing the built-in :func:`open` function which
|
||||
operates much differently.
|
||||
|
||||
.. index:: builtin: help
|
||||
|
||||
The builtin :func:`dir` and :func:`help` functions are useful as interactive
|
||||
The built-in :func:`dir` and :func:`help` functions are useful as interactive
|
||||
aids for working with large modules like :mod:`os`::
|
||||
|
||||
>>> import os
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue