class_docstr: Publish data with Publish-Subscribe pattern
  
  This allows clients and workers to directly communicate data between each
  other with a typical Publish-Subscribe pattern.  This involves two
  components,
  
  Pub objects, into which we put data:
  
      >>> pub = Pub('my-topic')
      >>> pub.put(123)
  
  And Sub objects, from which we collect data:
  
      >>> sub = Sub('my-topic')
      >>> sub.get()
      123
  
  Many Pub and Sub objects can exist for the same topic.  All data sent from
  any Pub will be sent to all Sub objects on that topic that are currently
  connected.  Pub's and Sub's find each other using the scheduler, but they
  communicate directly with each other without coordination from the
  scheduler.
  
  Pubs and Subs use the central scheduler to find each other, but not to
  mediate the communication.  This means that there is very little additional
  latency or overhead, and they are appropriate for very frequent data
  transfers.  For context, most data transfer first checks with the scheduler to find which
  workers should participate, and then does direct worker-to-worker
  transfers.  This checking in with the scheduler provides some stability
  guarantees, but also adds in a few extra network hops.  PubSub doesn't do
  this, and so is faster, but also can easily drop messages if Pubs or Subs
  disappear without notice.
  
  When using a Pub or Sub from a Client all communications will be routed
  through the scheduler.  This can cause some performance degradation.  Pubs
  and Subs only operate at top-speed when they are both on workers.
  
  Parameters
  ----------
  name: object (msgpack serializable)
      The name of the group of Pubs and Subs on which to participate.
  worker: Worker (optional)
      The worker to be used for publishing data. Defaults to the value of
      ```get_worker()```. If given, ``client`` must be ``None``.
  client: Client (optional)
      Client used for communication with the scheduler. Defaults to
      the value of ``get_client()``. If given, ``worker`` must be ``None``.
  
  Examples
  --------
  >>> pub = Pub('my-topic')
  >>> sub = Sub('my-topic')
  >>> pub.put([1, 2, 3])
  >>> sub.get()
  [1, 2, 3]
  
  You can also use sub within a for loop:
  
  >>> for msg in sub:  # doctest: +SKIP
  ...     print(msg)
  
  or an async for loop
  
  >>> async for msg in sub:  # doctest: +SKIP
  ...     print(msg)
  
  Similarly the ``.get`` method will return an awaitable if used by an async
  client or within the IOLoop thread of a worker
  
  >>> await sub.get()  # doctest: +SKIP
  
  You can see the set of connected worker subscribers by looking at the
  ``.subscribers`` attribute:
  
  >>> pub.subscribers
  {'tcp://...': {},
   'tcp://...': {}}
  
  See Also
  --------
  Sub
code: def __repr__(self):
      return f"<Pub: {self.name}>"
  
imports: from __future__ import annotations
  import asyncio
  import logging
  import threading
  import weakref
  from collections import defaultdict, deque
  from dask.utils import parse_timedelta
  from distributed.core import CommClosedError
  from distributed.metrics import time
  from distributed.protocol.serialize import to_serialize
  from distributed.utils import TimeoutError, sync, wait_for
label_desc: Use image node_id 4 for calling the Pub obj's underlying member method code with example usage: obj.__repr__() and returns: str, self, str