commit python3-jupyter_client for openSUSE:Factory

Hello community, here is the log from the commit of package python3-jupyter_client for openSUSE:Factory checked in at 2016-10-28 10:45:06 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/python3-jupyter_client (Old) and /work/SRC/openSUSE:Factory/.python3-jupyter_client.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Package is "python3-jupyter_client" Changes: -------- --- /work/SRC/openSUSE:Factory/python3-jupyter_client/python3-jupyter_client-doc.changes 2016-08-05 18:16:13.000000000 +0200 +++ /work/SRC/openSUSE:Factory/.python3-jupyter_client.new/python3-jupyter_client-doc.changes 2016-10-28 10:45:07.000000000 +0200 @@ -1,0 +2,11 @@ +Sun Oct 2 17:13:10 UTC 2016 - arun@gmx.de + +- update to version 4.4.0: + * Add :meth:`.KernelClient.load_connection_info` on KernelClient, + etc. for loading connection info directly from a dict, not just + from files. + * Include parent headers when adapting messages from older protocol + implementations (treats parent headers the same as headers). + * Compatibility fixes in tests for recent changes in ipykernel. + +------------------------------------------------------------------- python3-jupyter_client.changes: same change Old: ---- jupyter_client-4.3.0.tar.gz New: ---- jupyter_client-4.4.0.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ python3-jupyter_client-doc.spec ++++++ --- /var/tmp/diff_new_pack.qHsesQ/_old 2016-10-28 10:45:08.000000000 +0200 +++ /var/tmp/diff_new_pack.qHsesQ/_new 2016-10-28 10:45:08.000000000 +0200 @@ -24,7 +24,7 @@ %endif Name: python3-jupyter_client-doc -Version: 4.3.0 +Version: 4.4.0 Release: 0 Summary: Documentation for python3-jupyter_client License: BSD-3-Clause ++++++ python3-jupyter_client.spec ++++++ --- /var/tmp/diff_new_pack.qHsesQ/_old 2016-10-28 10:45:08.000000000 +0200 +++ /var/tmp/diff_new_pack.qHsesQ/_new 2016-10-28 10:45:08.000000000 +0200 @@ -17,7 +17,7 @@ Name: python3-jupyter_client -Version: 4.3.0 +Version: 4.4.0 Release: 0 Summary: Jupyter protocol implementation and client libraries License: BSD-3-Clause ++++++ jupyter_client-4.3.0.tar.gz -> jupyter_client-4.4.0.tar.gz ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/PKG-INFO new/jupyter_client-4.4.0/PKG-INFO --- old/jupyter_client-4.3.0/PKG-INFO 2016-06-07 10:30:20.000000000 +0200 +++ new/jupyter_client-4.4.0/PKG-INFO 2016-08-31 16:54:39.000000000 +0200 @@ -1,6 +1,6 @@ Metadata-Version: 1.1 Name: jupyter_client -Version: 4.3.0 +Version: 4.4.0 Summary: Jupyter protocol implementation and client libraries Home-page: http://jupyter.org Author: Jupyter Development Team diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/api/client.rst new/jupyter_client-4.4.0/docs/api/client.rst --- old/jupyter_client-4.3.0/docs/api/client.rst 2015-09-03 11:35:14.000000000 +0200 +++ new/jupyter_client-4.4.0/docs/api/client.rst 2016-08-31 10:32:24.000000000 +0200 @@ -10,6 +10,12 @@ .. autoclass:: KernelClient + .. automethod:: load_connection_file + + .. automethod:: load_connection_info + + .. automethod:: start_channels + .. automethod:: execute .. automethod:: complete diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/changelog.rst new/jupyter_client-4.4.0/docs/changelog.rst --- old/jupyter_client-4.3.0/docs/changelog.rst 2016-06-07 10:17:10.000000000 +0200 +++ new/jupyter_client-4.4.0/docs/changelog.rst 2016-08-31 10:32:24.000000000 +0200 @@ -4,6 +4,20 @@ Changes in Jupyter Client ========================= +4.4 +=== + +4.4.0 +----- + +`4.4 on GitHub https://github.com/jupyter/jupyter_client/milestones/4.4`__ + +- Add :meth:`.KernelClient.load_connection_info` on KernelClient, etc. for loading connection info + directly from a dict, not just from files. +- Include parent headers when adapting messages from older protocol implementations + (treats parent headers the same as headers). +- Compatibility fixes in tests for recent changes in ipykernel. + 4.3 === diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/conf.py new/jupyter_client-4.4.0/docs/conf.py --- old/jupyter_client-4.3.0/docs/conf.py 2015-11-27 16:15:59.000000000 +0100 +++ new/jupyter_client-4.4.0/docs/conf.py 2016-08-31 10:32:24.000000000 +0200 @@ -119,7 +119,7 @@ # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. -# html_theme = 'alabaster' +html_theme = 'sphinx_rtd_theme' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the @@ -297,3 +297,13 @@ # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = {'ipython': ('http://ipython.org/ipython-doc/dev/', None)} + +# Read The Docs +# on_rtd is whether we are on readthedocs.org, this line of code grabbed from docs.readthedocs.org +on_rtd = os.environ.get('READTHEDOCS', None) == 'True' + +if not on_rtd: # only import and set the theme if we're building docs locally + import sphinx_rtd_theme + html_theme = 'sphinx_rtd_theme' + html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] +# otherwise, readthedocs.org uses their theme by default, so no need to specify it diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/environment.yml new/jupyter_client-4.4.0/docs/environment.yml --- old/jupyter_client-4.3.0/docs/environment.yml 1970-01-01 01:00:00.000000000 +0100 +++ new/jupyter_client-4.4.0/docs/environment.yml 2016-08-31 10:33:26.000000000 +0200 @@ -0,0 +1,10 @@ +name: jup_client +channels: + - conda-forge +dependencies: +- pyzmq +- python=3 +- traitlets>=4.1 +- jupyter_core +- sphinx>=1.3.6 +- sphinx_rtd_theme diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/kernels.rst new/jupyter_client-4.4.0/docs/kernels.rst --- old/jupyter_client-4.3.0/docs/kernels.rst 2015-09-12 17:22:09.000000000 +0200 +++ new/jupyter_client-4.4.0/docs/kernels.rst 2016-07-13 05:12:42.000000000 +0200 @@ -112,6 +112,10 @@ Other locations may also be searched if the :envvar:`JUPYTER_PATH` environment variable is set. +Inside the kernel directory, three types of files are presently used: +``kernel.json``, ``kernel.js``, and logo image files. Currently, no other +files are used, but this may change in the future. + Inside the directory, the most important file is *kernel.json*. This should be a JSON serialised dictionary containing the following keys and values: diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/messaging.rst new/jupyter_client-4.4.0/docs/messaging.rst --- old/jupyter_client-4.3.0/docs/messaging.rst 2016-03-06 10:43:14.000000000 +0100 +++ new/jupyter_client-4.4.0/docs/messaging.rst 2016-08-31 16:52:45.000000000 +0200 @@ -141,6 +141,7 @@ so implementers are strongly encouraged to include it. It will be mandatory in 5.1. + .. _wire_protocol: The Wire Protocol @@ -190,7 +191,7 @@ If authentication is disabled, this should be an empty string. By default, the hashing function used for computing these signatures is sha256. -.. _HMAC: http://en.wikipedia.org/wiki/HMAC +.. _HMAC: https://en.wikipedia.org/wiki/HMAC .. note:: @@ -256,8 +257,38 @@ extended structure. -Messages on the shell ROUTER/DEALER sockets -=========================================== +Messages on the shell (ROUTER/DEALER) channel +============================================= + +.. _request_reply: + +Request-Reply +------------- + +In general, the ROUTER/DEALER sockets follow a request-reply pattern: + +The client sends an ``<action>_request`` message (such as ``execute_request``) on its shell (DEALER) socket. +The kernel receives that request and immediately publishes a ``status: busy`` message on IOPub. +The kernel then processes the request and sends the appropriate ``<action>_reply`` message, such as ``execute_reply``. +After processing the request and publishing associated IOPub messages, if any, +the kernel publishes a ``status: idle`` message. +This idle status message indicates that IOPub messages associated with a given request have all been received. + +All reply messages have a ``'status'`` field, which will have one of the following values: + +- ``status='ok'``: The request was processed successfully, and the remaining content of the reply is specified in the appropriate section below. +- ``status='error'``: The request failed due to an error. + When status is 'error', the usual content of a successful reply should be omitted, + instead the following fields should be present:: + + { + 'status' : 'error', + 'ename' : str, # Exception name, as a string + 'evalue' : str, # Exception value, as a string + 'traceback' : list(str), # traceback frames as strings + } + +- ``status='abort'``: the task has been aborted. In this case, no additional fields should be present. .. _execute: @@ -294,8 +325,9 @@ 'user_expressions' : dict, # Some frontends do not support stdin requests. - # If raw_input is called from code executed from such a frontend, - # a StdinNotImplementedError will be raised. + # If this is true, code running in the kernel can prompt the user for input + # with an input_request message (see below). If it is false, the kernel + # should not send these messages. 'allow_stdin' : True, # A boolean flag, which, if True, does not abort the execution queue, if an exception is encountered. @@ -390,26 +422,6 @@ ``user_variables`` is removed, use user_expressions instead. -When status is 'error', the following extra fields are present:: - - { - 'ename' : str, # Exception name, as a string - 'evalue' : str, # Exception value, as a string - - # The traceback will contain a list of frames, represented each as a - # string. For now we'll stick to the existing design of ultraTB, which - # controls exception level of detail statefully. But eventually we'll - # want to grow into a model where more information is collected and - # packed into the traceback object, with clients deciding how little or - # how much of it to unpack. But for now, let's start with a simple list - # of strings, since that requires only minimal changes to ultratb as - # written. - 'traceback' : list, - } - - -When status is 'abort', there are for now no additional data fields. This -happens when the kernel was interrupted by a signal. Payloads (DEPRECATED) ~~~~~~~~~~~~~~~~~~~~~ @@ -691,18 +703,27 @@ 'indent': str, } + Connect ------- +.. deprecated:: 5.1 + + connect_request/reply have not proved useful, and are considered deprecated. + Kernels are not expected to implement handlers for this message. + When a client connects to the request/reply socket of the kernel, it can issue a connect request to get basic information about the kernel, such as the ports the other ZeroMQ sockets are listening on. This allows clients to only have to know about a single port (the shell channel) to connect to a kernel. +The ports for any additional channels the kernel is listening on should be included in the reply. +If any ports are omitted from the reply, this indicates that the channels are not running. Message type: ``connect_request``:: - content = { - } + content = {} + +For example, a kernel with all channels running: Message type: ``connect_reply``:: @@ -711,8 +732,10 @@ 'iopub_port' : int, # The port the PUB socket is listening on. 'stdin_port' : int, # The port the stdin ROUTER socket is listening on. 'hb_port' : int, # The port the heartbeat socket is listening on. + 'control_port' : int, # The port the control ROUTER socket is listening on. } + .. _msging_comm_info: Comm info @@ -888,8 +911,10 @@ process is unlikely to respond in any useful way to messages. -Messages on the PUB/SUB socket -============================== +Messages on the IOPub (PUB/SUB) channel +======================================= + + Streams (stdout, stderr, etc) ------------------------------ @@ -1052,9 +1077,28 @@ execution_state : ('busy', 'idle', 'starting') } +When a kernel receives a request and begins processing it, +the kernel shall immediately publish a status message with ``execution_state: 'busy'``. +When that kernel has completed processing the request +and has finished publishing associated IOPub messages, if any, +it shall publish a status message with ``execution_state: 'idle'``. +Thus, the outputs associated with a given execution shall generally arrive +between the busy and idle status messages associated with a given request. + +.. note:: + + **A caveat for asynchronous output** + + Asynchronous output (e.g. from background threads) may be produced after the kernel + has sent the idle status message that signals the completion of the request. + The handling of these out-of-order output messages is currently undefined in this specification, + but the Jupyter Notebook continues to handle IOPub messages associated with a given request + after the idle message has arrived, + as long as the output area corresponding to that request is still active. + .. versionchanged:: 5.0 - Busy and idle messages should be sent before/after handling every message, + Busy and idle messages should be sent before/after handling every request, not just execution. .. note:: @@ -1087,17 +1131,29 @@ The selective clearing keys are ignored in v4 and the default behavior remains the same, so v4 clear_output messages will be safely handled by a v4.1 frontend. +.. _stdin_messages: -Messages on the stdin ROUTER/DEALER sockets -=========================================== +Messages on the stdin (ROUTER/DEALER) channel +============================================= -This is a socket where the request/reply pattern goes in the opposite direction: -from the kernel to a *single* frontend, and its purpose is to allow -``raw_input`` and similar operations that read from ``sys.stdin`` on the kernel -to be fulfilled by the client. The request should be made to the frontend that -made the execution request that prompted ``raw_input`` to be called. For now we -will keep these messages as simple as possible, since they only mean to convey -the ``raw_input(prompt)`` call. +With the stdin ROUTER/DEALER socket, the request/reply pattern goes in the +opposite direction of most kernel communication. +With the stdin socket, the kernel makes the request, and the single frontend +provides the response. +This pattern allows code to prompt the user for a line of input, +which would normally be read from stdin in a terminal. + +Many programming languages provide a function which displays a prompt, blocks +until the user presses return, and returns the text they typed before pressing +return. In Python 3, this is the ``input()`` function; in R it is called +``readline()``. If the :ref:`execute_request <execute>` message has +``allow_stdin==True``, kernels may implement these functions so that they send +an ``input_request`` message and wait for a corresponding ``input_reply``. The +frontend is responsible for displaying the prompt and getting the user's input. + +If ``allow_stdin`` is False, the kernel must not send ``stdin_request``. The +kernel may decide what to do instead, but it's most likely that calls to the +'prompt for input' function should fail immediately in this case. Message type: ``input_request``:: @@ -1114,7 +1170,10 @@ content = { 'value' : str } -When ``password`` is True, the frontend should not echo the input as it is entered. +When ``password`` is True, the frontend should not show the input as it is entered. +Different frontends may obscure it in different ways; e.g. showing each +character entered as the same neutral symbol, or not showing anything at all as +the user types. .. versionchanged:: 5.0 @@ -1130,14 +1189,10 @@ .. note:: - We do not explicitly try to forward the raw ``sys.stdin`` object, because in - practice the kernel should behave like an interactive program. When a - program is opened on the console, the keyboard effectively takes over the - ``stdin`` file descriptor, and it can't be used for raw reading anymore. - Since the IPython kernel effectively behaves like a console program (albeit - one whose "keyboard" is actually living in a separate process and - transported over the zmq connection), raw ``stdin`` isn't expected to be - available. + This pattern of requesting user input is quite different from how stdin works + at a lower level. The Jupyter protocol does not support everything code + running in a terminal can do with stdin, but we believe that this enables the + most common use cases. .. _kernel_heartbeat: diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/docs/wrapperkernels.rst new/jupyter_client-4.4.0/docs/wrapperkernels.rst --- old/jupyter_client-4.3.0/docs/wrapperkernels.rst 2016-04-09 01:38:38.000000000 +0200 +++ new/jupyter_client-4.4.0/docs/wrapperkernels.rst 2016-08-31 16:52:45.000000000 +0200 @@ -4,8 +4,8 @@ You can re-use IPython's kernel machinery to easily make new kernels. This is useful for languages that have Python bindings, such as `Octave http://www.gnu.org/software/octave/`_ (via -`Oct2Py http://blink1073.github.io/oct2py/docs/index.html`_), or languages -where the REPL can be controlled in a tty using `pexpect http://pexpect.readthedocs.org/en/latest/`_, +`Oct2Py https://blink1073.github.io/oct2py/#`_), or languages +where the REPL can be controlled in a tty using `pexpect http://pexpect.readthedocs.io/en/latest/`_, such as bash. .. seealso:: @@ -67,7 +67,7 @@ from ipykernel.kernelapp import IPKernelApp IPKernelApp.launch_instance(kernel_class=MyKernel) -Now create a `JSON kernel spec file http://jupyter-client.readthedocs.org/en/latest/kernels.html#kernel-specs`_ and install it using ``jupyter kernelspec install ``. Place your kernel module anywhere Python can import it (try current directory for testing). Finally, you can run your kernel using ``jupyter console --kernel <mykernelname>``. Note that ``<mykernelname>`` in the below example is ``echo``. +Now create a `JSON kernel spec file http://jupyter-client.readthedocs.io/en/latest/kernels.html#kernel-specs`_ and install it using ``jupyter kernelspec install ``. Place your kernel module anywhere Python can import it (try current directory for testing). Finally, you can run your kernel using ``jupyter console --kernel <mykernelname>``. Note that ``<mykernelname>`` in the below example is ``echo``. Example ------- diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/_version.py new/jupyter_client-4.4.0/jupyter_client/_version.py --- old/jupyter_client-4.3.0/jupyter_client/_version.py 2016-06-07 10:29:02.000000000 +0200 +++ new/jupyter_client-4.4.0/jupyter_client/_version.py 2016-08-31 16:53:33.000000000 +0200 @@ -1,4 +1,4 @@ -version_info = (4, 3, 0) +version_info = (4, 4, 0) __version__ = '.'.join(map(str, version_info)) protocol_version_info = (5, 0) diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/adapter.py new/jupyter_client-4.4.0/jupyter_client/adapter.py --- old/jupyter_client-4.3.0/jupyter_client/adapter.py 2015-11-27 16:15:59.000000000 +0100 +++ new/jupyter_client-4.4.0/jupyter_client/adapter.py 2016-08-08 15:17:18.000000000 +0200 @@ -126,6 +126,7 @@ def update_header(self, msg): msg['header'].pop('version', None) + msg['parent_header'].pop('version', None) return msg # shell channel @@ -231,6 +232,8 @@ def update_header(self, msg): msg['header']['version'] = self.version + if msg['parent_header']: + msg['parent_header']['version'] = self.version return msg # shell channel diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/connect.py new/jupyter_client-4.4.0/jupyter_client/connect.py --- old/jupyter_client-4.3.0/jupyter_client/connect.py 2016-03-06 10:43:14.000000000 +0100 +++ new/jupyter_client-4.4.0/jupyter_client/connect.py 2016-08-27 14:46:45.000000000 +0200 @@ -23,8 +23,9 @@ from traitlets.config import LoggingConfigurable from .localinterfaces import localhost from ipython_genutils.path import filefind -from ipython_genutils.py3compat import (str_to_bytes, bytes_to_str, cast_bytes_py2, - string_types) +from ipython_genutils.py3compat import ( + bytes_to_str, cast_bytes, cast_bytes_py2, string_types, +) from traitlets import ( Bool, Integer, Unicode, CaselessStrEnum, Instance, Type, ) @@ -411,23 +412,46 @@ self._connection_file_written = True - def load_connection_file(self): - """Load connection info from JSON dict in self.connection_file.""" - self.log.debug(u"Loading connection file %s", self.connection_file) - with open(self.connection_file) as f: - cfg = json.load(f) - self.transport = cfg.get('transport', self.transport) - self.ip = cfg.get('ip', self._ip_default()) + def load_connection_file(self, connection_file=None): + """Load connection info from JSON dict in self.connection_file. + + Parameters + ---------- + connection_file: unicode, optional + Path to connection file to load. + If unspecified, use self.connection_file + """ + if connection_file is None: + connection_file = self.connection_file + self.log.debug(u"Loading connection file %s", connection_file) + with open(connection_file) as f: + info = json.load(f) + self.load_connection_info(info) + + def load_connection_info(self, info): + """Load connection info from a dict containing connection info. + + Typically this data comes from a connection file + and is called by load_connection_file. + + Parameters + ---------- + info: dict + Dictionary containing connection_info. + See the connection_file spec for details. + """ + self.transport = info.get('transport', self.transport) + self.ip = info.get('ip', self._ip_default()) for name in port_names: - if getattr(self, name) == 0 and name in cfg: + if getattr(self, name) == 0 and name in info: # not overridden by config or cl_args - setattr(self, name, cfg[name]) + setattr(self, name, info[name]) - if 'key' in cfg: - self.session.key = str_to_bytes(cfg['key']) - if 'signature_scheme' in cfg: - self.session.signature_scheme = cfg['signature_scheme'] + if 'key' in info: + self.session.key = cast_bytes(info['key']) + if 'signature_scheme' in info: + self.session.signature_scheme = info['signature_scheme'] #-------------------------------------------------------------------------- # Creating connected sockets diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/launcher.py new/jupyter_client-4.4.0/jupyter_client/launcher.py --- old/jupyter_client-4.3.0/jupyter_client/launcher.py 2016-03-06 10:39:27.000000000 +0100 +++ new/jupyter_client-4.4.0/jupyter_client/launcher.py 2016-08-31 16:52:45.000000000 +0200 @@ -124,9 +124,13 @@ except Exception as exc: msg = ( "Failed to run command:\n{}\n" - "with kwargs:\n{!r}\n" + " PATH={!r}\n" + " with kwargs:\n{!r}\n" ) - msg = msg.format(cmd, kwargs) + # exclude environment variables, + # which may contain access tokens and the like. + without_env = {key:value for key, value in kwargs.items() if key != 'env'} + msg = msg.format(cmd, env.get('PATH', os.defpath), without_env) get_logger().error(msg) raise diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/tests/signalkernel.py new/jupyter_client-4.4.0/jupyter_client/tests/signalkernel.py --- old/jupyter_client-4.3.0/jupyter_client/tests/signalkernel.py 2016-03-10 10:09:45.000000000 +0100 +++ new/jupyter_client-4.4.0/jupyter_client/tests/signalkernel.py 2016-08-08 13:24:58.000000000 +0200 @@ -9,6 +9,7 @@ import sys import time +from ipykernel.displayhook import ZMQDisplayHook from ipykernel.kernelbase import Kernel from ipykernel.kernelapp import IPKernelApp @@ -61,7 +62,8 @@ class SignalTestApp(IPKernelApp): kernel_class = SignalTestKernel def init_io(self): - pass # disable stdout/stderr capture + # Overridden to disable stdout/stderr capture + self.displayhook = ZMQDisplayHook(self.session, self.iopub_socket) if __name__ == '__main__': # make startup artificially slow, diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/tests/test_connect.py new/jupyter_client-4.4.0/jupyter_client/tests/test_connect.py --- old/jupyter_client-4.3.0/jupyter_client/tests/test_connect.py 2016-03-06 10:38:36.000000000 +0100 +++ new/jupyter_client-4.4.0/jupyter_client/tests/test_connect.py 2016-07-28 16:33:39.000000000 +0200 @@ -12,7 +12,7 @@ from jupyter_core.application import JupyterApp from ipython_genutils.tempdir import TemporaryDirectory, TemporaryWorkingDirectory from ipython_genutils.py3compat import str_to_bytes -from jupyter_client import connect +from jupyter_client import connect, KernelClient from jupyter_client.consoleapp import JupyterConsoleApp from jupyter_client.session import Session @@ -92,6 +92,25 @@ nt.assert_equal(value, expected, "app.%s = %s != %s" % (attr, value, expected)) +def test_load_connection_info(): + client = KernelClient() + info = { + 'control_port': 53702, + 'hb_port': 53705, + 'iopub_port': 53703, + 'ip': '0.0.0.0', + 'key': 'secret', + 'shell_port': 53700, + 'signature_scheme': 'hmac-sha256', + 'stdin_port': 53701, + 'transport': 'tcp', + } + client.load_connection_info(info) + assert client.control_port == info['control_port'] + assert client.session.key.decode('ascii') == info['key'] + assert client.ip == info['ip'] + + def test_find_connection_file(): cfg = Config() with TemporaryDirectory() as d: