Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix outdated documentation on _conn, on_connect, and on_disconnect #469

Merged
merged 1 commit into from
Dec 18, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions docs/docs/services.rst
Original file line number Diff line number Diff line change
Expand Up @@ -67,15 +67,11 @@ If you wish to change the name of your service, or specify a list of aliases, se
The first name in this list is considered the "proper name" of the service, while the rest
are considered aliases. This distinction is meaningless to the protocol and the registry server.

Your service class may also define two special methods: ``on_connect(self)`` and
``on_disconnect(self)``. These methods are invoked, not surprisingly, when a connection
Your service class may also define two special methods: ``on_connect(self, conn)`` and
``on_disconnect(self, conn)``. These methods are invoked, not surprisingly, when a connection
has been established, and when it's been disconnected. Note that during ``on_disconnect``,
the connection is already dead, so you can no longer access any remote objects.

Other than that, your service instance has the ``_conn`` attribute, which represents the
:class:`~rpyc.core.protocol.Connection` that it serves. This attribute already
exists when ``on_connected`` is called.

.. note::
Try to avoid overriding the ``__init__`` method of the service. Place all initialization-related
code in ``on_connect``.
Expand Down Expand Up @@ -109,8 +105,11 @@ it's not the most common use case, two-sides services are quite useful. Consider
And this server::

class ServerService(rpyc.Service):
def on_connect(self, conn):
self.conn = conn

def exposed_bar(self):
return self._conn.root.foo() + "bar"
return self.conn.root.foo() + "bar"

The client can invoke ``conn.root.bar()`` on the server, which will, in turn, invoke ``foo`` back
on the client. The final result would be ``"foobar"``.
Expand Down