[DATALAD RUNCMD] run codespell throughout

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^

CHANGELOG.rst

@@ -118,7 +118,7 @@ Improvements
 - Fixed teleport function behavior for keyword-only arguments with default `#422`_
 - Improved documentation on custom exception handling
 - Fixed IPv6 support for server `#407`_
-- Added a simple asynchrounous service example `#400`_
+- Added a simple asynchronous service example `#400`_
 
 .. _#425: https://github.com/tomerfiliba-org/rpyc/issues/425
 .. _#412: https://github.com/tomerfiliba-org/rpyc/pull/412
@@ -240,7 +240,7 @@ Backward Incompatibilities
 * no longer store connection as ``self._conn``. (allows services that serve
   multiple clients using the same service object, see `#198`_).
 
-* ``SlaveService`` is now split into two asymetric classes: ``SlaveService``
+* ``SlaveService`` is now split into two asymmetric classes: ``SlaveService``
   and ``MasterService``. The slave exposes functionality to the master but can
   not anymore access remote objects on the master (`#232`_, `#248`_).
   If you were previously using ``SlaveService``, you may experience problems

demos/boilerplate/ReadMe.md

@@ -2,7 +2,7 @@
 
 This service is ispired by the FileMonitor example.
 
-It will monitor the file `/tmp/test.txt` to geenrate asynchrounous events that will be notified to the RPyC client.
+It will monitor the file `/tmp/test.txt` to generate asynchronous events that will be notified to the RPyC client.
 
 run in one terminal:
 

demos/chat/readme.txt

@@ -19,11 +19,11 @@ a message to a chat server is analogous to calling a function on the server,
 while receiving messages from the chat server is analogous to the server
 calling an(async) function on the client. RPC at its best.
 
-Also, do keep in mind the inherent securiy of this model: the server exposes
+Also, do keep in mind the inherent security of this model: the server exposes
 a well defined set of methods(so there's no risk of the client abusing
                               the server), while the server can't abuse the client because it can invoke
 only a designated callback it is passed. This allows both parties not to
-trust each other while still providing RPyC-grade servive.
+trust each other while still providing RPyC-grade service.
 
 
 == Threading issues ==
@@ -33,7 +33,7 @@ at least the one I provide, is single-threaded.
 
 == Client Design ==
 With all the visual noise caused by the GUI code, it's easy to get lost on
-the RPyC part. In short, this is the RPyC releated code:
+the RPyC part. In short, this is the RPyC related code:
 
     def on_message(text):
         # server-side callback

docs/docs/security.rst

@@ -4,7 +4,7 @@ Security
 ========
 Operating over a network always involve a certain security risk, and requires some awareness.
 Version 3 of RPyC was a rewrite of the library, specifically targeting security and
-service-orientation. Unlike version 2.6, RPyC no longer makes use of unsecure protocols like ``pickle``,
+service-orientation. Unlike version 2.6, RPyC no longer makes use of insecure protocols like ``pickle``,
 supports :data:`security-related configuration parameters <rpyc.core.protocol.DEFAULT_CONFIG>`,
 comes with strict defaults, and encourages the use of a capability-based security model. Even so, it behooves you to
 take a layered to secure programming and not let RPyC be a single point of failure.
@@ -23,7 +23,7 @@ Of course, you can use RPyC over a :ref:`secure connection <ssl>`, to mitigate t
 RPyC works by exposing a root object, which in turn may expose other objects (and so on). For
 instance, if you expose a module or an object that has a reference to the ``sys`` module,
 a user may be able to reach it. After reaching ``sys``, the user can traverse ``sys.modules`` and
-gain access to all of the modules that the server imports. More complex methodologies, similiar to those used in ``CVE-2019-16328``,
+gain access to all of the modules that the server imports. More complex methodologies, similar to those used in ``CVE-2019-16328``,
 could leverage access to ``builtins.str``, ``builtins.type``, ``builtins.object``, and ``builtins.dict`` and gain access to
 ``sys`` modules. The default configurations for RPyC are intended to mitigate access to dangerous objects. But if you enable
 ``allow_public_attrs``, return uninitialized classes or override ``_rpyc_getattr`` such things are likely to slip under the radar

docs/docs/usecases.rst

@@ -56,7 +56,7 @@ and access the device programmatically with ease (using ``ctypes`` or ``popen``
 
 Parallel Execution
 ------------------
-In CPython, the `GIL <http://wiki.python.org/moin/GlobalInterpreterLock>`_ prevents mutliple
+In CPython, the `GIL <http://wiki.python.org/moin/GlobalInterpreterLock>`_ prevents multiple
 threads from executing python bytecode at once. This simplifies the design of the python
 interpreter, but the consequence of which is that CPython cannot utilize multiple/multicore
 CPUs. The only way to achieve scalable, CPU-bound python programs is to use multiple processes,

docs/index.rst

@@ -74,7 +74,7 @@ Features
   protocol, and requiring no complex setup (name servers, HTTP, URL-mapping, etc.)
 
 * **Secure** - employs a `Capability based <http://en.wikipedia.org/wiki/Capability-based_security>`_
-  security model; intergrates easily with SSH
+  security model; integrates easily with SSH
 
 * **Zero-Deploy Enabled** -- Read more about :ref:`Zero-Deploy RPyC <zerodeploy>`
 

docs/install.rst

@@ -45,7 +45,7 @@ language features were added. These changes render the two major versions
 of Python incompatible with one another, and sadly, this cannot be bridged
 automatically by RPyC at the serialization layer.
 
-It's not that I didn't try -- it's just too hard a feat. It's bascially like
+It's not that I didn't try -- it's just too hard a feat. It's basically like
 writing a 100% working `2to3 <http://docs.python.org/library/2to3.html>`_ tool,
 alongside with a matching ``3to2`` one; and that, I reckon, is comparable to
 the *halting problem* (of course I might be wrong here, but it still doesn't

docs/tutorial/tut1.rst

@@ -57,7 +57,7 @@ is how you see the server's command line::
     >>> rsys.argv
     ['bin/rpyc_classic.py']
 
-…add module search pathes for the server's import mechanism::
+…add module search paths for the server's import mechanism::
 
     >>> rsys.path.append('/tmp/totally-secure-package-location)
 

docs/tutorial/tut5.rst

@@ -1,6 +1,6 @@
 .. _tut5:
 
-Part 5: Asynchrounous Operation and Events
+Part 5: Asynchronous Operation and Events
 ==========================================
 
 Asynchronism

rpyc/core/netref.py

@@ -99,7 +99,7 @@ class BaseNetref(with_metaclass(NetrefMetaclass, object)):
     defined in the :data:`_builtin_types`), and they are shared between all
     connections.
 
-    The rest of the netref classes are created by :meth:`rpyc.core.protocl.Connection._unbox`,
+    The rest of the netref classes are created by :meth:`rpyc.core.protocol.Connection._unbox`,
     and are private to the connection.
 
     Do not use this class directly; use :func:`class_factory` instead.
@@ -326,7 +326,7 @@ def class_factory(id_pack, methods):
     # create methods that must perform a syncreq
     for name, doc in methods:
         name = str(name)  # IronPython issue #10
-        # only create methods that wont shadow BaseNetref during merge for mro
+        # only create methods that won't shadow BaseNetref during merge for mro
         if name not in LOCAL_ATTRS:  # i.e. `name != __class__`
             ns[name] = _make_method(name, doc)
     return type(netref_name, (BaseNetref,), ns)

rpyc/core/protocol.py

@@ -367,7 +367,7 @@ def _dispatch_request(self, seq, raw_args):  # dispatch
             handler, args = raw_args
             args = self._unbox(args)
             res = self._HANDLERS[handler](self, *args)
-        except:  # TODO: revist how to catch handle locally, this should simplify when py2 is dropped
+        except:  # TODO: revisit how to catch handle locally, this should simplify when py2 is dropped
             # need to catch old style exceptions too
             t, v, tb = sys.exc_info()
             self._last_traceback = tb
@@ -734,7 +734,7 @@ def poll_all(self, timeout=0):  # serving
     def sync_request(self, handler, *args):
         """requests, sends a synchronous request (waits for the reply to arrive)
 
-        :raises: any exception that the requets may be generated
+        :raises: any exception that the requests may be generated
         :returns: the result of the request
         """
         timeout = self._config["sync_request_timeout"]

rpyc/lib/compat.py

@@ -171,7 +171,7 @@ def poll(self, timeout=None):
 def with_metaclass(meta, *bases):
     """Create a base class with a metaclass."""
     # dummy metaclass that replaces itself with the actual metaclass after
-    # one level of class instanciation:
+    # one level of class instantiation:
     class metaclass(type):
         def __new__(cls, name, this_bases, d):
             return meta(name, bases, d)

rpyc/utils/classic.py

@@ -163,7 +163,7 @@ def connect_thread():
 def connect_multiprocess(args={}):
     """
     Starts a SlaveService on a multiprocess process and connects to it.
-    Useful for testing purposes and running multicore code thats uses shared
+    Useful for testing purposes and running multicore code that's uses shared
     memory. See :func:`rpyc.utils.factory.connect_multiprocess`
 
     :returns: an RPyC connection exposing ``SlaveService``

rpyc/utils/server.py

@@ -374,7 +374,7 @@ def _drop_connection(self, fd):
         '''removes a connection by closing it and removing it from internal structs'''
         conn = None
 
-        # cleanup fd_to_conn dictionnary
+        # cleanup fd_to_conn dictionary
         try:
             conn = self.fd_to_conn[fd]
             del self.fd_to_conn[fd]