Remove duplicate module ids and fix links

Author: sloria

docs/api_reference.rst

@@ -10,15 +10,15 @@ Schema
 ======
 
 
-.. autoclass:: Schema
+.. autoclass:: marshmallow.Schema
     :inherited-members:
 
-.. autoclass:: SchemaOpts
+.. autoclass:: marshmallow.SchemaOpts
 
-.. autoclass:: MarshalResult
-.. autoclass:: UnmarshalResult
+.. autoclass:: marshmallow.MarshalResult
+.. autoclass:: marshmallow.UnmarshalResult
 
-.. autofunction:: pprint
+.. autofunction:: marshmallow.pprint
 
 .. _api_fields:
 

docs/upgrading.rst

@@ -37,7 +37,7 @@ In 2.0, validation/deserialization of `None` is consistent across field types. I
 Default Values
 **************
 
-Before version 2.0, certain fields (including `fields.String`, `fields.List`, `fields.Nested` and number fields) had implicit default values that would be used if their corresponding input value was `None` or missing.
+Before version 2.0, certain fields (including `String <marshmallow.fields.String>`, `List <marshmallow.fields.List>`, `Nested <marshmallow.fields.Nested>`, and number fields) had implicit default values that would be used if their corresponding input value was `None` or missing.
 
 
 In 2.0, these implicit defaults are removed.  A `Field's <marshmallow.fields.Field>` ``default`` parameter is only used if you explicitly set it. Otherwise, missing inputs will be excluded from the serialized output.
@@ -259,8 +259,6 @@ For a full list of changes in 2.0, see the :ref:`Changelog <changelog>`.
 Upgrading to 1.2
 ++++++++++++++++
 
-.. module:: marshmallow.fields
-
 Validators
 **********
 
@@ -306,8 +304,6 @@ The `Decimal` field was added to support serialization/deserialization of `decim
 Upgrading to 1.0
 ++++++++++++++++
 
-.. module:: marshmallow
-
 Version 1.0 marks the first major release of marshmallow. Many big changes were made from the pre-1.0 releases in order to provide a cleaner API, support object deserialization, and improve field validation.
 
 Perhaps the largest change is in how objects get serialized. Serialization occurs by invoking the :meth:`Schema.dump` method rather than passing the object to the constructor.  Because only configuration options (e.g. the ``many``, ``strict``, and ``only`` parameters) are passed to the constructor, you can more easily reuse serializer instances.  The :meth:`dump <Schema.dump>` method also forms a nice symmetry with the :meth:`Schema.load` method, which is used for deserialization.
@@ -339,8 +335,6 @@ Perhaps the largest change is in how objects get serialized. Serialization occur
 
     Some crucial parts of the pre-1.0 API have been retained to ease the transition. You can still pass an object to a `Schema` constructor and access the `Schema.data` and `Schema.errors` properties. The `is_valid` method, however, has been completely removed. It is recommended that you migrate to the new API to prevent future releases from breaking your code.
 
-.. module:: marshmallow.fields
-
 The Fields interface was also reworked in 1.0 to make it easier to define custom fields with their own serialization and deserialization behavior. Custom fields now implement :meth:`Field._serialize` and :meth:`Field._deserialize`.
 
 .. code-block:: python

docs/why.rst

@@ -1,5 +1,4 @@
 .. _why:
-.. module:: marshmallow
 
 Why marshmallow?
 ================
@@ -18,7 +17,7 @@ Marshmallow makes no assumption about web frameworks or database layers. It will
 Concise, familiar syntax.
 -------------------------
 
-If you have used `Django REST Framework`_ or  `WTForms <http://wtforms.simplecodes.com/docs/1.0.3/>`_, marshmallow's :class:`Schema` syntax will feel familiar to you. Class-level field attributes define the schema for formatting your data. Configuration is added using the :ref:`class Meta <meta_options>` paradigm. Configuration options can be overriden at application runtime by passing arguments to the :class:`Schema` constructor. The :meth:`dump <Schema.dump>` and :meth:`load <Schema.load>` methods are used for serialization and deserialization (of course!).
+If you have used `Django REST Framework`_ or  `WTForms <http://wtforms.simplecodes.com/docs/1.0.3/>`_, marshmallow's :class:`Schema` syntax will feel familiar to you. Class-level field attributes define the schema for formatting your data. Configuration is added using the :ref:`class Meta <meta_options>` paradigm. Configuration options can be overriden at application runtime by passing arguments to the `Schema <marshmallow.Schema>` constructor. The :meth:`dump <marshmallow.Schema.dump>` and :meth:`load <marshmallow.Schema.load>` methods are used for serialization and deserialization (of course!).
 
 Class-based schemas allow for code reuse and configuration.
 -----------------------------------------------------------
@@ -30,7 +29,7 @@ Consistency meets flexibility.
 
 Marshmallow makes it easy to modify a schema's output at application runtime. A single :class:`Schema` can produce multiple outputs formats while keeping the individual field outputs consistent.
 
-As an example, you might have a JSON endpoint for retrieving all information about a video game's state. You then add a low-latency endpoint that only returns a minimal subset of information about game state. Both endpoints can be handled by the same :class:`Schema`.
+As an example, you might have a JSON endpoint for retrieving all information about a video game's state. You then add a low-latency endpoint that only returns a minimal subset of information about game state. Both endpoints can be handled by the same `Schema <marshmallow.Schema>`.
 
 .. code-block:: python
 
@@ -62,7 +61,7 @@ Context-aware serialization.
 
 Marshmallow schemas can modify their output based on the context in which they are used. Field objects have access to a ``context`` dictionary that can be changed at runtime.
 
-Here's a simple example that shows how a :class:`Schema` can anonymize a person's name when a boolean is set on the context.
+Here's a simple example that shows how a `Schema <marshmallow.Schema>` can anonymize a person's name when a boolean is set on the context.
 
 .. code-block:: python