Merge branch 'master' into release-0.5.0

Author: njsmith

docs/source/quickstart.rst

@@ -137,7 +137,7 @@ But now we're using virtual time, so the call to ``await
 trio.sleep(1)`` takes *exactly* 1 virtual second, and the ``==`` test
 will pass every time. Before, we had to wait around for the test to
 complete; now, it completes essentially instantaneously. (Try it!)
-And, while here our example is super simple, it's integration with
+And, while here our example is super simple, its integration with
 Trio's core scheduling logic allows this to work for arbitrarily
 complex programs (as long as they aren't interacting with the outside
 world).
@@ -288,7 +288,7 @@ server. Sometimes this will work fine. But it takes a little while for
 the server to start up and be ready to accept connections – so other
 times, randomly, our connection attempt will happen too quickly, and
 error out. After all – ``nursery.start_soon`` only promises that the
-task will be started *soon*, not that it's actually happened. So this
+task will be started *soon*, not that it has actually happened. So this
 test will be flaky, and flaky tests are the worst.
 
 Fortunately, Trio makes this easy to solve, by switching to using
@@ -338,7 +338,7 @@ Well, there's no way to predict the port ahead of time. But after
 :func:`~trio.serve_tcp` has opened a port, it can check and see what
 it got. So we need some way to pass this data back out of
 :func:`~trio.serve_tcp`. Fortunately, ``nursery.start`` handles this
-too: it lets the task pass out a piece of data after it's started. And
+too: it lets the task pass out a piece of data after it has started. And
 it just so happens that what :func:`~trio.serve_tcp` passes out is a
 list of :class:`~trio.SocketListener` objects. And there's a handy
 function called :func:`trio.testing.open_stream_to_socket_listener`

docs/source/reference.rst

@@ -19,7 +19,7 @@ When Trio mode is enabled, two extra things happen:
   have to do it yourself.
 * Async fixtures using ``@pytest.fixture`` automatically get converted
   to Trio fixtures. (The main effect of this is that it helps you
-  catch mistakes where a you use an async fixture with a non-async
+  catch mistakes like using an async fixture with a non-async
   test.)
 
 There are two ways to enable Trio mode.

pytest_trio/plugin.py

@@ -91,10 +91,10 @@ def pytest_exception_interact(node, call, report):
 # and do something sensible with it.
 #
 # You should think of fixtures as a dependency graph: each fixtures *uses*
-# zero or more other fixtures, and is *used by* zero or more other fixtures. A
-# fixture should be setup before any of the fixtures it's used by are setup,
-# and it should be torn down as soon as all of the fixtures that use it are
-# torn down. And at root of this dependency graph, we have the test itself,
+# zero or more other fixtures, and is *used by* zero or more other fixtures.
+# A fixture should be setup before any of its dependees are setup, and torn
+# down once all of its dependees have terminated.
+# At the root of this dependency graph, we have the test itself,
 # which is just like a fixture except that instead of having a separate setup
 # and teardown phase, it runs straight through.
 #