Remove trailing space in doc/

docs/api.rst

@@ -5,13 +5,13 @@ API Reference
 
 Serialization
 -------------
-.. toctree::   
+.. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    api/core_brine
 
-* :ref:`api-brine` - A simple and fast serialization format for immutable data (numbers, string, 
+* :ref:`api-brine` - A simple and fast serialization format for immutable data (numbers, string,
   tuples, etc.). Brine is the "over-the-wire" encoding format of RPyC.
 
 * :ref:`api-vinegar` - A configurable serializer for exceptions. Vinegar extracts the exception's
@@ -22,7 +22,7 @@ IO Layer
 .. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    api/core_stream
 
 * :ref:`api-stream` - The stream layer (byte-oriented, platform-agnostic streams)
@@ -34,7 +34,7 @@ Protocol
 .. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    api/core_netref
    api/core_protocol
    api/core_service
@@ -44,7 +44,7 @@ Protocol
 
 * :ref:`api-service` - The RPyC service model
 
-* :ref:`api-netref` - Implementation of transparent object proxies (netrefs) 
+* :ref:`api-netref` - Implementation of transparent object proxies (netrefs)
 
 * :ref:`api-async` - Asynchronous object proxies (netrefs)
 
@@ -53,16 +53,16 @@ Server-Side
 .. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    api/utils_server
    api/utils_authenticators
    api/utils_registry
 
-* :ref:`api-server` - The core implementation of RPyC servers; includes the implementation of 
+* :ref:`api-server` - The core implementation of RPyC servers; includes the implementation of
   the forking and threaded servers.
 
 * :ref:`api-registry` - Implementation of the Service Registry; the registry is a bonjour-like
-  discovery agent, with which RPyC servers register themselves, and allows clients to locate 
+  discovery agent, with which RPyC servers register themselves, and allows clients to locate
   different servers by name.
 
 * :ref:`api-authenticators` - Implementation of two common authenticators, for SSL and TLSlite.
@@ -76,24 +76,24 @@ Client-Side
    api/utils_factory
    api/utils_classic
 
-* :ref:`api-factory` - general-purpose connection factories (over pipes, sockets, SSL, SSH, 
+* :ref:`api-factory` - general-purpose connection factories (over pipes, sockets, SSL, SSH,
   TLSlite, etc.)
 
 * :ref:`api-classic` - *Classic-mode* factories and utilities
 
-* :ref:`api-helpers` - Various helpers (``timed``, ``async``, ``buffiter``, ``BgServingThread``, 
+* :ref:`api-helpers` - Various helpers (``timed``, ``async``, ``buffiter``, ``BgServingThread``,
   etc.)
 
 Misc
 ----
 .. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    api/utils_splitbrain
    api/utils_zerodeploy
 
-* :ref:`api-zerodeploy` - Deploy short-living RPyC servers on remote machines with ease - all you'll 
+* :ref:`api-zerodeploy` - Deploy short-living RPyC servers on remote machines with ease - all you'll
   need is SSH access and a Python interpreter installed on the host
 
 * :ref:`api-splitbrain` - Run code on the local machine, but have it operating on a remote one! The splitbrain

docs/api/core_protocol.rst

@@ -1,6 +1,6 @@
 .. _api-protocol:
 
-Protocol 
+Protocol
 ========
 
 .. automodule:: rpyc.core.protocol

docs/docs.rst

@@ -9,7 +9,7 @@ Introduction
 .. toctree::
    :maxdepth: 1
    :hidden:
-   
+
    docs/about
    docs/theory
    docs/howto
@@ -18,13 +18,13 @@ Introduction
    docs/capabilities
 
 
-* :ref:`A little about RPyC <about>` - related projects, contributors, and 
+* :ref:`A little about RPyC <about>` - related projects, contributors, and
   logo issues
 
-* :ref:`Theory of Operation <theory>` - background on the inner workings of 
-  RPyC and the terminology 
+* :ref:`Theory of Operation <theory>` - background on the inner workings of
+  RPyC and the terminology
 
-* :ref:`Use cases <use-cases>` - some common use-cases, demonstrating the power 
+* :ref:`Use cases <use-cases>` - some common use-cases, demonstrating the power
   and ease of RPyC
 
 * :ref:`How to's <howto>` - solutions to specific problems
@@ -48,9 +48,9 @@ Reference
    docs/splitbrain
 
 
-* :ref:`Servers <servers>` - using the built-in servers and writing custom ones 
+* :ref:`Servers <servers>` - using the built-in servers and writing custom ones
 
-* :ref:`Classic RPyC <classic>` - using RPyC in *slave mode* (AKA *classic 
+* :ref:`Classic RPyC <classic>` - using RPyC in *slave mode* (AKA *classic
   mode*), where the client has unrestricted control over the server.
 
 * :ref:`RPyC Services <services>` - writing well-defined services which restrict
@@ -62,7 +62,7 @@ Reference
 * :ref:`Security Concerns <security>` - keeping security in mind when using
   RPyC
 
-* :ref:`Secure Connections <ssl>` - create an encrypted and authenticated 
+* :ref:`Secure Connections <ssl>` - create an encrypted and authenticated
   connection over SSL or SSH
 
 * :ref:`Zero-Deploy <zerodeploy>` - spawn temporary, short-lived RPyC server on remote

docs/docs/about.rst

@@ -2,10 +2,10 @@
 
 About RPyC
 ==========
-RPyC was inspired by the work of **Eyal Lotem** on 
-`pyinvoke <http://pybuild.sourceforge.net/pyinvoke.html>`_, which pioneered in 
-the field of "dynamic RPC" (where there's no predefined contract between the 
-two sides). The two projects, however, are completely unrelated in any other 
+RPyC was inspired by the work of **Eyal Lotem** on
+`pyinvoke <http://pybuild.sourceforge.net/pyinvoke.html>`_, which pioneered in
+the field of "dynamic RPC" (where there's no predefined contract between the
+two sides). The two projects, however, are completely unrelated in any other
 way. RPyC is developed and maintained by `Tomer Filiba <http://tomerfiliba.com>`_
 (tomerfiliba@gmail.com).
 

docs/docs/async.rst

@@ -4,7 +4,7 @@ Asynchronous Operation
 ======================
 Many times, especially when working in a client-server model, you may want to perform
 operations "in the background", i.e., send a batch of work to the server and continue
-with your local operation. At some later point, you may want to poll for the completion 
+with your local operation. At some later point, you may want to poll for the completion
 of the work, or perhaps be notified of its completion using a callback function.
 
 RPyC is very well-suited for asynchronous work. In fact, the protocol itself is asynchronous,
@@ -15,9 +15,9 @@ asynchronous behavior.
 
 async()
 -------
-The wrapper :func:`async <rpyc.utils.helpers.async>` takes any *callable* 
-:ref:`netref <api-netref>` and returns an asynchronous-wrapper around that netref. 
-When invoked, this wrapper object dispatches the request and immediately returns an 
+The wrapper :func:`async <rpyc.utils.helpers.async>` takes any *callable*
+:ref:`netref <api-netref>` and returns an asynchronous-wrapper around that netref.
+When invoked, this wrapper object dispatches the request and immediately returns an
 :class:`AsyncResult <rpyc.core.async.AsyncResult>`, instead of waiting for the response.
 
 Usage
@@ -28,14 +28,14 @@ Create an async wrapper around the server's ``time.sleep`` function ::
 
 And invoke it like any other function, but instead of blocking, it will immediately
 return an ``AsyncResult`` ::
-  
+
     res = async_sleep(5)
-    
+
 Which means your client can continue working normally, while the server
 performs the request. Do note, however, that the server is "busy" sleeping,
 and will not respond to new requests until the operation completes (unless you
 started your request on a separate thread)
-    
+
 You can test for completion using ``res.ready``, wait for completion using ``res.wait()``,
 and get the result using ``res.value``. You may set a timeout for the result using
 ``res.set_expiry()``, or even register a callback function to be invoked when the
@@ -48,7 +48,7 @@ Therefore, you must hold a strong reference to the returned proxy. Particularly,
 that instead of doing ::
 
     res = async(conn.root.myfunc)(1,2,3)
-   
+
 Use ::
 
     myfunc_async = async(conn.root.myfunc)
@@ -59,8 +59,8 @@ timed()
 -------
 :class:`timed <rpyc.utils.helpers.timed>` allows you to set a timeout for a synchronous invocation.
 When a ``timed`` function is invoked, you'll synchronously wait for the result, but no longer
-than the specified timeout. Should the invocation take longer, a 
-:class:`AsyncResultTimeout <rpyc.core.async.AsyncResultTimeout>` will be raised. 
+than the specified timeout. Should the invocation take longer, a
+:class:`AsyncResultTimeout <rpyc.core.async.AsyncResultTimeout>` will be raised.
 
 Under the hood, ``timed`` is actually implemented with ``async``: it begins dispatches the
 operation, sets a timeout on the ``AsyncResult``, and waits for the response.
@@ -71,11 +71,11 @@ Example
 
     # allow this function to take up to 6 seconds
     timed_sleep = rpyc.timed(conn.modules.time.sleep, 6)
-    
+
     # wait for 3 seconds -- works
     async_res = timed_sleep(3)  # returns immediately
     async_res.value             # returns after 3 seconds
-    
+
     # wait for 10 seconds -- fails
     async_res = timed_sleep(10) # returns immediately
     async_res.value             # raises AsyncResultTimeout
@@ -97,7 +97,7 @@ calls, while still being able to process incoming request (normally from the ser
 the server to send "events" (i.e., invoke callbacks on the client side) while the client is busy
 doing other things.
 
-For a detailed example show-casing the ``BgServingThread``, see :ref:`tut5-events` in the 
+For a detailed example show-casing the ``BgServingThread``, see :ref:`tut5-events` in the
 tutorial.
 
 

docs/docs/classic.rst

@@ -2,7 +2,7 @@
 
 Classic
 =======
-Prior to version 3, RPyC employed a modus-operandi that's now referred to as 
+Prior to version 3, RPyC employed a modus-operandi that's now referred to as
 "classic mode". In this mode, the server was completely under the control of its
 client -- there was no way to restrict what the client could do, and there was
 no notion of :ref:`services <services>`. A client simply connected to a server
@@ -18,19 +18,19 @@ See also the :ref:`API reference <api-classic>`
 
 Usage
 -----
-RPyC installs ``rpyc_classic.py`` to your Python scripts directory (e.g., ``C:\PythonXX\Scripts``, 
+RPyC installs ``rpyc_classic.py`` to your Python scripts directory (e.g., ``C:\PythonXX\Scripts``,
 ``/usr/local/bin``, etc.), which is a ready-to-run classic-mode server. It can be configured
 with :ref:`command-line parameters <classic-server>`. Once you have it running, you can connect
 to it like so ::
 
     conn = rpyc.classic.connect("hostname")    # use default TCP port (18812)
-    
+
     proc = conn.modules.subprocess.Popen("ls", stdout = -1, stderr = -1)
     stdout, stderr = proc.communicate()
     print stdout.split()
-    
+
     remote_list = conn.builtin.range(7)
-    
+
     conn.execute("print 'foo'")