Thanks for the excellent JEP @MSeal and @willingc! I'm overall very much +1 on the idea, I only have one quick note - it might be worth mentioning what are the expected implications for interaction with notebook clients that may discard this field when saving, esp. any clients out there that might not rely on our own nbformat for file management. I don't know if it's worth at least a note of what the implications for users might be, and I don't know the current state of clients like pycharm or vscode in that regard.

But that's a very minor point, adding my official +1 to the overall proposal, and no worries if you feel it won't add much useful info. Just a suggestion. Thanks again for the great work!

Indeed @lrennels! We've been mostly using the Pangeo discourse as a home for announcements/discussions related to this effort, and can hopefully direct more resources there to strengthen that as the space where a Jupyter/Pangeo community focused on geosciences can grow. Glad to hear this matches successes in your experience, thx :)

Idea suggested by @lheagy in discussion - let's contact some of the participants in today's call and suggest a recorded "office hours" where we help onboard them and take their questions, but make that available later to the public.

Thanks for the input @takluyver! Given that at this point formal discussion had wrapped up, it would be great if you could convey your official stance by voting.

But obviously we can continue refining and clarifying things, especially as a working group is forming up that will necessarily have to pin down the specifics of the process.

To answer a few points (I'm tight on time and will need to revisit the others later):

• Regarding contributors you may not know well: we expect in the nomination process to have a little summary of the person's contributions, so that others can make a reasonably informed judgment. This is a reality of every larger organization, where it becomes necessary to make a call on people you may not be closely familiar with, so hopefully we can provide a concise but informative summary of the value of their work.

• Regarding $$$: we went back and forth quite a bit on this and we agreed that it would both raise the perceived importance of the recognition (since we want this to be seen as a meaningful professional signal to give back to those who give to Jupyter) and also could be for many people (if not all) a concretely valuable reward. But we can certainly leave the option for people to donate back their award to the project if they'd rather not deal with the tax/etc details; I suggest this is something the working group can flush out. Also, "nominal" I think was code for "not particularly large" - the idea is that this won't make anyone rich and the money isn't the main incentive, but we still want it to be useful as stated above.

• Re. the Steering Council: This is basically step 1 in our governance restructuring process (whose minutes we've been posting on Discourse) to evolve the SC into a new body, with the recognition part decoupled from governance management. So for now we'd just seed the DC group with the current SC + new faces, and that would be a strictly recognition-only group. Next we'll be posting more PRs to transition the "management" part of the SC into a new model as well, you can see the current drafts for all that work in the linked docs from the governance meeting threads - all are also welcome to join our public meetings on Tuesday mornings US Pacific time!

Done @jasongrout, see link above! I suggest closing this one then as I think its scope is now well handled in current Lab.

Problem

There's a clear use case for running notebooks while ignoring errors, #4026 has further context. That issue is now well handled (should probably close soon) but its approach is based on per-cell metadata.

Users sometimes want to be able to run a whole notebook past cells that may error out purely while doing exploratory work, and in that scenario having to manually either remove the error cells or tag them manually is an unnecessary burden.

Proposed Solution

A stateful toggle in the "Run" menu called "Ignore all errors when running cells" would let users easily switch between the two behaviors.

That would be per-session and global, so much more coarse-grained than the metadata tags, but perhaps a useful tool for many users who may want to experiment with quick runs rather than carefully annotate teaching-oriented notebooks.

Added postBuild to configure the necessary JupyterLab extensions (Jupyter widgets, matplotlib/widget and voilà), and made default binder target be the JupyterLab UI.

It seems to me that this issue is now largely handled, at least at the level of how classic did, by honoring the raises-exception tag (I just wonder if we should have called that causes-error to be a bit more generic regarding languages that don't use the term "exception").

So I wonder if it should be closed?

I only have one idea/suggestion left, but that could be a separate, purely UI/UX issue: it might work to have a stateful toggle in the "Run" menu called "Ignore all errors when running cells" for people to easily switch between the two behaviors. That would be per-session and global, so much more coarse-grained than the metadata tags, but perhaps a useful tool for many users who may want to experiment with quick runs rather than carefully annotate teaching-oriented notebooks.

@jasongrout if you think that's worth discussing but it belongs better in a separate issue I'm happy to open one :)

The syzygy one is restricted to "full" accounts.

Ah, understood. Merged now, but in the long run it might have more impact to update a bit our binder/r2d docs with these patterns. I ended up getting quite a bit of 'private help' from @choldgraf on Slack on this, though I'd read a fair bit of the docs already (and it's not my first time building slightly more complex binders with custom compiled dependencies). I'll sync with Chris/Yuvi/Erik/etc on that and will try to contribute to the docs themselves.

Thanks so much for pitching in, and more importantly - for all you've done to make Binder the incredible resource it is today!!

Thanks everyone! @Carreau huge appreciation for your fast turnaround - I was tied up this morning :)

Very glad to see this collaboration between the python and jupyter/binder teams. We hope this helps the discussion on the pep, for me it's also a great test of how to use Binder/Jupyter to facilitate projects experimenting with new features or testing their code against early alphas/betas of Python itself or other libraries. We often see projects worry that others don't test against their early releases until it's too late, and having easy-to-use binders available can be a pattern that helps facilitate this process.

@gvanrossum and @brandtbucher - I very much appreciate your feedback and being receptive to our input. Best of luck with the PEP!

Done! You can test the PR again via the binder link. It should open with the rendered versions of the README and EXAMPLES files for reference, and with a 'playground' notebook ready to go. You can view a static, non-executable version of the playground notebook here for quick reference without having to wait for the binder to start.

Sounds good - if I don’t get to it this eve I’ll drop these updates in tomorrow, thx for the feedback!

Do you prefer it fully empty or with a couple of simple illustrations from expr to get people going? I was just playing with something like:

I can update the PR with a notebook that opens with that so people don't have just a blank page, or I can leave it nearly blank (I'll put a header and a version check at least for sanity).

Just LMK and I can update the PR. Huge thanks @Carreau for the fixes!

Do you mean whether I should change the README above, or whether that should be added to the r2d/binder docs?

@choldgraf thanks! I avoided over-riding the python name itself out of fear it could cause other issues with running Jupyter, but I'll try to test that idea later. On second thought, it might be OK actually, and would make things easier...

In this PR about PEP-6222 I created an experimental build of Python 3.10 that is available at this binder link. However if I try to install using py10 -m pip install pyzmq, the build fails:

[ lots of elided early output]

    building 'zmq.backend.cython._device' extension
    creating build/temp.linux-x86_64-3.10/zmq
    creating build/temp.linux-x86_64-3.10/zmq/backend
    creating build/temp.linux-x86_64-3.10/zmq/backend/cython
    gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DHAVE_SYS_UN_H=1 -Ibundled/zeromq/include -Izmq/utils -I/home/jovyan/.local/include/python3.10 -c zmq/backend/cython/_device.c -o build/temp.linux-x86_64-3.10/zmq/backend/cython/_device.o
    gcc -pthread -shared build/temp.linux-x86_64-3.10/zmq/backend/cython/_device.o -o build/lib.linux-x86_64-3.10/zmq/backend/cython/_device.cpython-310-x86_64-linux-gnu.so
    building 'zmq.backend.cython._poll' extension
    gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DHAVE_SYS_UN_H=1 -Ibundled/zeromq/include -Izmq/utils -I/home/jovyan/.local/include/python3.10 -c zmq/backend/cython/_poll.c -o build/temp.linux-x86_64-3.10/zmq/backend/cython/_poll.o
    zmq/backend/cython/_poll.c: In function ‘__Pyx_PyList_Append’:
    zmq/backend/cython/_poll.c:1252:23: error: lvalue required as left operand of assignment
             Py_SIZE(list) = len+1;
                           ^
    error: command '/usr/bin/gcc' failed with exit code 1
    ----------------------------------------
ERROR: Command errored out with exit status 1: /home/jovyan/.local/bin/py10 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-up2ewe5s/pyzmq/setup.py'"'"'; __file__='"'"'/tmp/pip-install-up2ewe5s/pyzmq/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-gjmp6rt5/install-record.txt --single-version-externally-managed --compile --install-headers /home/jovyan/.local/include/python3.10/pyzmq Check the logs for full command output.

This may or may not be an easy fix, not sure, but I figured I'd flag it in case it's doable. Having pyzmq support would help us to try to get a Jupyter kernel for python 3.10 so folks could more easily experiment with new language features via a pre-built binder that has all the right environment.

Here's an example of the crash that results from %run test_patma.py in the binder link above. I

In [6]: run test_patma.py                                                                                                          
Traceback (most recent call last):
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/cache.py", line 109, in wrapper
    return dct[key]
KeyError: ((), frozenset())

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/ptutils.py", line 113, in get_completions
    yield from self._get_completions(body, offset, cursor_position, self.ipy_completer)
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/ptutils.py", line 126, in _get_completions
    for c in completions:
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/core/completer.py", line 438, in _deduplicate_completions
    completions = list(completions)
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/core/completer.py", line 1818, in completions
    for c in self._completions(text, offset, _timeout=self.jedi_compute_type_timeout/1000):
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/core/completer.py", line 1861, in _completions
    matched_text, matches, matches_origin, jedi_matches = self._complete(
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/core/completer.py", line 2029, in _complete
    completions = self._jedi_matches(
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/core/completer.py", line 1373, in _jedi_matches
    interpreter = jedi.Interpreter(
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/api/__init__.py", line 858, in __init__
    super(Interpreter, self).__init__(code, environment=environment,
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/api/__init__.py", line 184, in __init__
    self._inference_state = InferenceState(
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/inference/__init__.py", line 91, in __init__
    self.grammar = environment.get_grammar()
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/cache.py", line 111, in wrapper
    result = method(self, *args, **kwargs)
  File "/home/jovyan/.local/lib/python3.10/site-packages/jedi/api/environment.py", line 37, in get_grammar
    return parso.load_grammar(version=version_string)
  File "/home/jovyan/.local/lib/python3.10/site-packages/parso/grammar.py", line 260, in load_grammar
    return load_grammar(**kwargs)
  File "/home/jovyan/.local/lib/python3.10/site-packages/parso/grammar.py", line 236, in load_grammar
    version_info = parse_version_string(version)
  File "/home/jovyan/.local/lib/python3.10/site-packages/parso/utils.py", line 176, in parse_version_string
    return _parse_version(version)
  File "/home/jovyan/.local/lib/python3.10/site-packages/parso/utils.py", line 125, in _parse_version
    raise ValueError('The given version is not in the right format. '
ValueError: The given version is not in the right format. Use something like "3.8" or "3".

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jovyan/.local/bin/ipython", line 8, in <module>
    sys.exit(start_ipython())
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/__init__.py", line 126, in start_ipython
    return launch_new_instance(argv=argv, **kwargs)
  File "/home/jovyan/.local/lib/python3.10/site-packages/traitlets/config/application.py", line 664, in launch_instance
    app.start()
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/ipapp.py", line 356, in start
    self.shell.mainloop()
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 563, in mainloop
    self.interact()
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 546, in interact
    code = self.prompt_for_code()
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 472, in prompt_for_code
    text = self.pt_app.prompt(
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/shortcuts/prompt.py", line 994, in prompt
    return self.app.run(set_exception_handler=set_exception_handler)
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/application/application.py", line 811, in run
    return loop.run_until_complete(
  File "/home/jovyan/.local/lib/python3.10/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/application/application.py", line 778, in run_async
    return await _run_async2()
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/application/application.py", line 766, in _run_async2
    await self.cancel_and_wait_for_background_tasks()
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/application/application.py", line 867, in cancel_and_wait_for_background_tasks
    await task
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/buffer.py", line 1854, in new_coroutine
    await coroutine(*a, **kw)
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/buffer.py", line 1683, in async_completer
    async for completion in self.completer.get_completions_async(
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/completion/base.py", line 269, in get_completions_async
    async for completion in completer.get_completions_async(
  File "/home/jovyan/.local/lib/python3.10/site-packages/prompt_toolkit/completion/base.py", line 196, in get_completions_async
    for item in self.get_completions(document, complete_event):
  File "/home/jovyan/.local/lib/python3.10/site-packages/IPython/terminal/ptutils.py", line 116, in get_completions
    print_tb(e)
  File "/home/jovyan/.local/lib/python3.10/traceback.py", line 53, in print_tb
    print_list(extract_tb(tb, limit=limit), file=file)
  File "/home/jovyan/.local/lib/python3.10/traceback.py", line 72, in extract_tb
    return StackSummary.extract(walk_tb(tb), limit=limit)
  File "/home/jovyan/.local/lib/python3.10/traceback.py", line 347, in extract
    for f, lineno in frame_gen:
  File "/home/jovyan/.local/lib/python3.10/traceback.py", line 312, in walk_tb
    yield tb.tb_frame, tb.tb_lineno
AttributeError: 'ValueError' object has no attribute 'tb_frame'

It seems that something changed in the structure of exception/traceback objects. There may be other issues as well, this is just the first problem I saw.

In this PR about PEP-6222 I created an experimental build of Python 3.10 that is available at this binder link. However if I install IPython using py10 -m pip install IPython and then try to use it, eventually I get a crash. I'll post the details in a comment below so we keep the top-level issue description simple. It would be great to track 3.10 compatibility, if possible, so we can use IPython for testing/experimenting with new features and ideas (though I realize that may be a big lift in that it's tracking quite a moving target).

Indeed at this point it only offers command-line support, not notebooks. I figured that could still be useful as it means folks don't need to do the 3.10a build themselves, but it would be much better to have full Jupyter support, so that examples could be presented as full notebooks. That was my original hope...

As for how much work it would be, I'm not 100% sure - my very quick-and-dirty tests showed me two problems:

• IPython installs but crashes immediately. It seems there's some changes in the traceback-related attributes held in under sys that break its assumptions.

• For a full kernel we also need pyzmq support, and that failed to build, apparently due to some changes in the C API.

I didn't debug either case other than reading the resulting error, so I have no idea if they are quick and easy fixes or complex ones. Pinging @minrk and @Carreau in case they have any quick ideas (folks, no worries if not).

I'll open issues on both of those projects to at least track their 3.10 support status, linking to this.

One option would be to add a small, short note at the end of the README (rather than a very visible button at the top) that just says something along the lines of

**Trying this out with binder:** if you'd like to experiment with this, click on [this binder link](URL) - it will take you to a live environment where you can open a terminal and run the examples by calling `python3.10` or `py10`, which is a build of the necessary versions of both this repository, CPython 3.10alpha, and the necessary dependencies.

That would let us have this merged in so folks can more easily come along and help/iterate, without drawing unsuspecting users in... Or we could just merge the PR with zero changes to the top-level README, and only a post on python-dev (which I'm happy to do). My only interest is to facilitate iteration, so whatever works for you and your community/stakeholders, we (me and others in Jupyter, probably :) are happy to help with.

• Sorry @gvanrossum - I should have been clearer in the PR description, I'll update that in a minute (I had the info about the different between the system python 3.7 and the 3.10alpha for these tests in the README but not at the top).

For clarity here: to run any of the PEP 622 code, the Python 3.10 alpha that needs to be used is @brandtbucher's, which is available in this build as python3.10 or as py10 (I made that up for convenience). mypy and pytest were also installed under python3.10, so they are available via their normal commands (as python3.10 is first on $PATH ahead of the system stuff).

• @brandtbucher yes, on any new commits of this repo it will rebuild against the latest patma rev. There's a new github action that can be used to improve integration between a repo's updates and repo2docker/binder. I haven't used it yet, but perhaps @choldgraf/@yuvipanda/@betatim have further input on how to most usefully integrate that here.

Thanks for the input - I'm happy to iterate to make this useful!

Given that testing these examples requires building a special branch of Python 3.10, I figured it might facilitate discussion to add binder support to this repo. The files in the binder directory do that, and the resulting environment is available by clicking on the following link/image:

If you like this PR and decide to integrate it, please let me know before merging and I can add a version of the above to the top-level README, pointing to the right repo (rather than to my fork as above) so anyone who visits the repo can find the link.

I should note that as of right now, I get a segfault when I try to run the tests:

Thanks to @choldgraf and @yuvipanda for help and tips while I was creating this - a few things in this binder are a bit non-standard as we're adding a custom Python, so a few careful manual steps need to be taken.