Add a section on using resolver methods to the docs

Author: Cito

docs/modules/execution.rst

@@ -1,8 +1,6 @@
 Execution
 =========
 
-.. py:module:: graphql.execution
-
 .. automodule:: graphql.execution
 
 .. autofunction:: execute

docs/usage/index.rst

@@ -11,6 +11,7 @@ and serving queries against that type schema.
    resolvers
    queries
    sdl
+   methods
    introspection
    parser
    extension

docs/usage/methods.rst

@@ -0,0 +1,58 @@
+Using resolver methods
+----------------------
+
+Above we have attached resolver functions to the schema only. However, it is
+also possible to define resolver methods on the resolved objects, starting with
+the ``root_value`` object that you can pass to the :func:`graphql.graphql`
+function when executing a query.
+
+In our case, we could create a ``Root`` class with three methods as root
+resolvers, like so::
+
+    class Root():
+        """The root resolvers"""
+
+        def hero(self, info, episode):
+            return luke if episode == 5 else artoo
+
+        def human(self, info, id):
+            return human_data.get(id)
+
+        def droid(self, info, id):
+            return droid_data.get(id)
+
+
+Since we haven't defined synchronous methods only, we will use the
+:func:`graphql.graphql_sync` function to execute a query, passing
+a ``Root()`` object as the ``root_value``::
+
+    from graphql import graphql_sync
+
+    result = graphql_sync(schema, """
+        {
+          droid(id: "2001") {
+            name
+            primaryFunction
+          }
+        }
+        """, Root())
+    print(result)
+
+Even if we haven't attached a resolver to the ``hero`` field as we did above,
+this would now still resolve and give the following output::
+
+    ExecutionResult(
+        data={'droid': {'name': 'R2-D2', 'primaryFunction': 'Astromech'}},
+        errors=None)
+
+Of course you can also define asynchronous methods as resolvers, and execute
+queries asynchronously with :func:`graphql.graphql`.
+
+In a similar vein, you can also attach resolvers as methods to the resolved
+objects on deeper levels than the root of the query. In that case, instead
+of resolving to dictionaries with keys for all the fields, as we did above,
+you would resolve to objects with attributes for all the fields. For instance,
+you would define a class ``Human`` with a method :meth:`friends` for resolving
+the friends of a human. You can also make use of inheritance in this case.
+The ``Human`` class and a ``Droid`` class could inherit from a ``Character``
+class and use its methods as resolvers for common fields.

docs/usage/other.rst

@@ -1,7 +1,7 @@
 Other Usages
 ------------
 
-GraphQLL-core-next provides many more low-level functions that can be used to
+GraphQL-core-next provides many more low-level functions that can be used to
 work with GraphQL schemas and queries. We encourage you to explore the contents
 of the various :ref:`sub-packages`, particularly :mod:`graphql.utilities`,
 and to look into the source code and tests of `GraphQL-core-next`_ in order

graphql/language/parser.py

@@ -46,14 +46,14 @@ def parse(source: SourceType, no_location=False,
     definition. They'll be represented in the `variable_definitions` field
     of the `FragmentDefinitionNode`.
 
-    The syntax is identical to normal, query-defined variables. For example:
+    The syntax is identical to normal, query-defined variables. For example::
 
         fragment A($var: Boolean = false) on T  {
           ...
         }
 
     If `experimental_variable_definition_directives` is set to True, the parser
-    understands directives on variable definitions:
+    understands directives on variable definitions::
 
         query Foo($var: String = "abc" @variable_definition_directive) {
           ...