Corrected some small typos

Fixes #16

source/comparisons.rst

@@ -43,7 +43,7 @@ In Python 2, ``__cmp__(self, other)`` implemented comparison between two
 objects, returning a negative value if ``self < other``, positive if
 ``self > other``, and zero if they were equal.
 
-This approach of trepresenting comparison results is common in C-style
+This approach of representing comparison results is common in C-style
 languages. But, early in Python 2 development, it became apparent that
 only allowing three cases for the relative order of objects is too limiting.
 
@@ -211,7 +211,7 @@ one way to sort it by last name in Python 2 would be::
 This function is called many times – O(*n* log *n*) – during the comparison.
 
 As an alternative to *cmp*, sorting functions can take a keyword-only ``key``
-parameter, a function that returs the key under which to sort::
+parameter, a function that returns the key under which to sort::
 
     >>> def keyfunction(item):
     ...     """Key for comparison by last name"""
@@ -227,7 +227,7 @@ the many comparisons are then handled by optimized C code.
 Also, in most cases key functions are more readable than *cmp*: usually,
 one thinks of sorting by some aspect of an object (such as last name),
 rather than by comparing individual objects.
-The main disdvantage is that the old *cmp* style is commonly used in
+The main disadvantage is that the old *cmp* style is commonly used in
 C-language APIs, so external libraries are likely to provide similar functions.
 
 In Python 3, the ``cmp`` parameter was removed, and only ``key`` (or no

source/dicts.rst

@@ -33,7 +33,7 @@ a :meth:`~py3:object.__contains__` method to it to implement the
 ``in`` operator.
 If possible, mark the ``has_key`` method as deprecated.
 Then run the fixer, and review the output.
-Typically, the fixer's changes will need to be be reverted in tests for the
+Typically, the fixer's changes will need to be reverted in tests for the
 ``has_key`` method itself.
 
 If you are using objects with unrelated semantics for the attribute
@@ -206,7 +206,7 @@ and less readable.
 However, the fixer cannot detect that the list is only used for iteration,
 so it emits overly defensive code.
 
-In this case, both speed and readibility can be improved by iterating over
+In this case, both speed and readability can be improved by iterating over
 the dict itself::
 
     for key in dictionary:

source/exceptions.rst

@@ -14,7 +14,7 @@ Exceptions are now instances of dedicated classes.
 They contain all information about the error: the type, value and traceback.
 
 This chapter mentions all exception-related changes needed to start
-supportingPython 3.
+supporting Python 3.
 
 
 .. _except-syntax:
@@ -128,7 +128,7 @@ Iterating Exceptions
 * :ref:`Fixer <python-modernize>`: ``python-modernize -wnf libmodernize.fixes.fix_except``
 * Prevalence: Rare
 
-In Python 2, exceptions were *iterable*. so it was possible to “unpack” the
+In Python 2, exceptions were *iterable*, so it was possible to “unpack” the
 arguments of an exception as part of the ``except`` statement::
 
     except RuntimeError as (num, message):
@@ -138,7 +138,7 @@ In Python 3, this is no longer true::
     except RuntimeError as e:
         num, message = e.args
 
-The reccommended fixer catches the easy cases of unpacking in ``except``
+The recommended fixer catches the easy cases of unpacking in ``except``
 statements.
 If your code iterates through exceptions elsewhere, you need to manually
 change it to iterate over ``args`` instead.
@@ -184,7 +184,7 @@ The :class:`py2:StandardError` class is removed in Python 3.
 It was the base class for built-in exceptions, and it proved to be an
 unnecessary link in almost any exception's inheritance chain.
 
-The reccommended fixer will replace all uses of ``StandardError`` with
+The recommended fixer will replace all uses of ``StandardError`` with
 ``Exception``.
 Review the result to check if this is correct: for example, code might rely
 on the name of an exception class, or on exceptions not derived from

source/imports.rst

@@ -2,7 +2,7 @@ Importing
 ---------
 
 Python 3 brings a complete overhaul of the way ``import`` works,
-but developer-visible changes
+but developer-visible changes can be summarised as follows.
 
 
 Absolute imports
@@ -52,8 +52,8 @@ In Python 3, the feature becomes the default.
 
 To prepare for this, make sure all imports are either absolute, or *explicitly*
 relative.
-Both the ``mypkg.collections`` stlye and the ``.collections`` style are
-adequate; we recommend the former for increased readibility [#f1]_.
+Both the ``mypkg.collections`` style and the ``.collections`` style are
+adequate; we recommend the former for increased readability [#f1]_.
 
 The recommended fixer simply adds the future import to all files that
 do a potentially ambiguous import.

source/iterators.rst

@@ -20,7 +20,7 @@ to apply a more specific fix.
 
 * Prevalence: Common
 
-in Python 3, the :func:`py3:map` and :func:`py3:filter` functions return
+In Python 3, the :func:`py3:map` and :func:`py3:filter` functions return
 iterators (``map`` or ``filter`` objects, respectively).
 In Python 2, they returned lists.
 

source/numbers.rst

@@ -49,7 +49,7 @@ Special Methods
 
 To overload the ``/`` operator for a class in Python 2, one defined
 the ``__div__`` special method.
-With the divisoin change, there are two methods to define:
+With the division change, there are two methods to define:
 
 
 * ``__floordiv__``
@@ -91,8 +91,8 @@ The ``long`` builtin no longer exists.
 However, calling ``int`` on a number that doesn't fit in Python 2's ``int``
 range will automatically create a ``long`` with the appropriate value.
 
-The same automatic conversion to long happens on all operations on ``int``
-that overflow: for example, ``10**50`` results in a long on most systems.
+The same automatic conversion to ``long`` happens on all operations on ``int``
+that overflow: for example, ``10**50`` results in a ``long`` on most systems.
 
 The range of Python 2's ``int`` is system-dependent.
 Together with the automatic conversion, this means that code that depends

source/process.rst

@@ -13,9 +13,9 @@ Before you start porting, any libraries that your code imports need to run
 with Python 3.
 Check if this is the case.
 
-As first you can get porting status information from ``setup.py`` or
+Porting status information of a library is usually available in ``setup.py`` or
 ``setup.cfg`` files, where compatible Python versions can be mentioned in
-classifiers.
+``classifiers`` argument to ``setup()``.
 
 Some projects took advantage of the backwards incompatible upgrade to clean
 up their interfaces.

source/stdlib-reorg.rst

@@ -61,7 +61,7 @@ The ``urllib`` modules
 * Prevalence: Common
 
 The :mod:`py2:urllib`, :mod:`py2:urllib2` and :mod:`py2:urlparse` modules were
-reorganized more heavily, with individual functions and classes reistributed to
+reorganized more heavily, with individual functions and classes redistributed to
 submodules of Python 3's :mod:`urllib`: :mod:`urllib.parse`, :mod:`urllib.error`,
 :mod:`urllib.request`, and :mod:`urllib.response`.
 

source/strings.rst

@@ -15,15 +15,15 @@ In Python 2, the ``str`` type was used for two different kinds of values –
     This type is available as ``str`` in Python 3, and ``unicode``
     in Python 2.
 
-    In code, we will refer to this type as ``unicode`` – a short, unabmbiguous
+    In code, we will refer to this type as ``unicode`` – a short, unambiguous
     name, although one that is not built-in in Python 3.
     Some projects refer to it as ``six.text_type`` (from the :ref:`six`
     library).
 
 *
 
     **Bytes** or *bytestring* is a binary serialization format suitable for
-    storing data on on disk or sending it over the wire. It is a sequence of
+    storing data on disk or sending it over the wire. It is a sequence of
     integers between 0 and 255.
     Most data – images, sound, configuration info, or *text* – can be
     serialized (encoded) to bytes and deserialized (decoded) from
@@ -53,7 +53,7 @@ can use what is conceptually a third type:
     The **native string** (``str``) – text in Python 3, bytes in Python 2
 
 Custom ``__str__`` and ``__repr__`` methods, and code that deals with
-Python language objects (such as atribute/function names) will always need to
+Python language objects (such as attribute/function names) will always need to
 use the native string, because that is what each version of Python uses
 for text-like data.
 
@@ -63,7 +63,7 @@ For other data, you can use the native string in these circumstances:
     * Under Python 2, each “native string” value has a well-defined encoding
       (such as ``UTF-8`` or :func:`py2:locale.getpreferredencoding`)
     * You do not mix native strings with either bytes or text – always
-      encode/decode dilligently when converting to these types.
+      encode/decode diligently when converting to these types.
 
 Native strings affect the semantics under Python 2 as little as possible,
 while not requiring the resulting Python 3 API to feel bad. But, adding

source/syntax.rst

@@ -3,7 +3,7 @@ Syntax Changes
 
 Python 3 cleaned up some warts of the language's syntax.
 
-The changes needed to accomodate this are mostly mechanical, with
+The changes needed to accommodate this are mostly mechanical, with
 little chance of breaking code, so they work well as the first patches
 to send to a project when intending to port it.
 
@@ -105,7 +105,7 @@ The Inequality Operator
 In the spirit of “There's only one way to do it”, Python 3 removes the
 little-known alternate spelling for inequality: the ``<>`` operator.
 
-The recommended fixer will replace all occurences with ``!=``.
+The recommended fixer will replace all occurrences with ``!=``.
 
 
 New Reserved Words

source/tools.rst

@@ -3,7 +3,7 @@ Tools
 
 Several tools exist to automate as much of the porting as possible,
 and to check for common errors.
-Here is a survey of tools we reccommend.
+Here is a survey of tools we recommend.
 
 
 python -3
@@ -20,7 +20,7 @@ six
 When porting a large piece of software, it is desirable to support both
 Python 2 and Python 3 in the same codebase.
 Many projects will need this dual support for a long time,
-but even those that can drop Python 2 support as soon as the port is done
+but even those that can drop Python 2 support as soon as the port is done,
 will typically go through a period of adding Python 3 support,
 in which the software should continue to work on Python 2.
 
@@ -29,7 +29,7 @@ version-straddling code by offering compatibility wrappers over
 the differences.
 
 For example, the Python 3 syntax for specifying metaclasses is not valid
-Python 2, ande the Python 2 way does nothing in Python 3,
+Python 2, and the Python 2 way does nothing in Python 3,
 so ``six`` provides an ``add_metaclass`` decorator for this purpose.
 It also provides stable names for standard library modules that were
 moved or reorganized in Python 3.