JupyterLab for an Enhanced Notebook Experience

Working With Multiple Notebooks

Next you’ll learn how JupyterLab helps you work with multiple notebooks. To do this, of course, you’ll need to create another notebook.

Keep your Population Data notebook open and open a second one. To do this, click the New Launcher ‘+’ tab. Now launch another notebook by clicking the Python 3 icon under the Notebook heading. A second notebook will launch in its own tab. Right-click this tab and rename the notebook Population Changes:

As you can see, the notebook tabs are placed beside each other. To keep things looking professional, you might like to add some Markdown explaining a little about the intended content of your Population Changes notebook:

### Population Changes Since 1980

The data shown below shows the decade-on-decade increases in the
[world's population](https://www.worldometers.info/world-population/world-population-by-year/)
since 1980.

Again, don’t forget to run the Markdown cell using Shift+Enter to render it into the cell.

Although the current notebook arrangement makes it easy to flip between them by clicking their tabs, suppose you wanted to use this second notebook to analyze your world population data. The first thing you’d need to do is add in the population data from your Population Data workbook. You could, of course, copy and paste, but JupyterLab allows you to drag cells directly between different notebooks, provided you can see them both simultaneously:

To display notebooks side by side, you dragged the tab of the Population Changes notebook down and to the right of the Population Data notebook. When you released your mouse, both workbooks became viewable.

Then, to copy the cells between notebooks, you selected the cell containing the decades and population lists in Population Data. You know you’ve selected it when a blue vertical bar appears to the right of the cell.

Finally, you grabbed the margin area as shown and dragged it across onto Population Changes before dropping it. You used the fine blue horizontal line that appeared as a placement guide.

Adding a Python Library Into a Notebook

Next, you’ll analyze the Population Changes notebook. To do this, you need to add some more code and import the pandas library.

In a code cell immediately below the one that you just copied across, add in the following code:

def calculate_differences(data_set):
    differences = [0]
    for index in range(1, len(data_set)):
        differences.append(round(data_set[index] - data_set[index - 1], 1))
    return differences

population_change = calculate_differences(population)

Your calculate_differences() function accepts a list of numbers and calculates the differences between each of its elements. These differences are returned as a separate list. The final line of code calls the function and stores the returned list when you run the cell. Nothing will be displayed.

Before you go any further, make sure to run this cell to ensure its content is known to the underlying kernel.

Next you’ll create a pandas DataFrame. Having your data in a pandas DataFrame allows you to perform lots of data analysis on it. Here you’ll settle for a neat table containing the data.

pandas is another module that’s not part of the native Python language, so you’ll need to install it. To do so, add a new code cell and use !python -m pip install pandas. Run the cell, and pandas will install. Check the final line of the output to make sure there were no installation errors. You can then delete the output of the pip install command by selecting its cell and sending it to trash.

Once you’ve successfully installed pandas, you can use it to analyze your data any way you wish. Here you only want a DataFrame, so add the following code into a code cell in your notebook:

import pandas as pd

zipped = list(zip(decades, population, population_change))
columns=["Decade", "Population(Bn)", "Change"]
population_df = pd.DataFrame(zipped, columns=columns)

print(population_df)

To use the pandas module that you just installed, you must import it. You then use Python’s built-in zip function to iterate over each of your lists in parallel and produce a collection of tuples with an item from each one. You then pass that collection into the pandas DataFrame constructor to produce a DataFrame. In addition, you specify the columns of the DataFrame using the columns parameter.

As you can see when you run the cell, the DataFrame displays as a neat table:

Did you know that the world’s population is increasing at a nearly constant rate each decade? Oh, the things you learn from Real Python tutorials!

Looking at Views

If you have a long file, you may need to scroll down to view what you’re interested in. To overcome this, JupyterLab allows you to create multiple synchronized views of your files. When you create a new view on a file such as a notebook, you’re creating a new interface for accessing it. Each view allows you to look at separate parts of your file at the same time. What’s more, if you change a notebook, its view updates as well.

Suppose you want to view your Matplotlib chart outside of its notebook. To do this, you create a new view of your chart in its own tab. However, the chart will still be linked to the underlying notebook code. If you change the chart’s data in the notebook, then you’ll update the chart in both the notebook and the view. This is very useful if your notebook is long and you want to see different parts of it at the same time.

Select your Population Data notebook and then the cell containing the Matplotlib code:

Now right-click on the cell or the existing chart and select Create New View for Cell Output. A new view tab will appear below the notebook. You can move the position of the view around the screen to wherever you wish by dragging and dropping its tab. The view will always display the same content regardless of which cells you’re looking at in its underlying notebook:

As you can see, the new view appears immediately below the notebook that it’s a view of. Feel free to change the data contained in your population data notebook and rerun its cell as well as the cell containing the chart. In addition to updating the chart in the notebook, this will also update it in the view.

If you close the notebook, you’ll close the view. Unlike notebooks, views aren’t saved. To close the view alone, simply close it by clicking the X on its tab.

Of course, creating multiple views when combined with opening multiple files can be very useful, but it would be tiresome having to open everything up again each time you restart JupyterLab. Fortunately, you don’t actually have to, as you’ll see next.

Working With Workspaces

A JupyterLab workspace is a saved layout of its various components, such as open notebooks and terminals. By default, JupyterLab saves changes to your layout automatically. This allows you to continue with the same layout that you had when you last closed it. You’ll find this very useful if you perform your analysis over many sessions.

If you’re working on multiple projects that all need their own sets of files or other components opened simultaneously, you can save their layout as a custom workspace so that you can quickly return to it again later.

A workspace is a JSON file containing information about the files it contains and their layout on-screen. This means that if you delete the workspace file, you won’t delete any files that it references.

It’s possible to save the layout of the contents of a JupyterLab session, including its views. To do this, you save the workspace. First of all, make sure you’ve saved everything. You can do this quickly by choosing the File → Save All menu option. To save the layout, select File → Save Current Workspace As, and then give it a name such as population_analysis.jupyterlab-workspace. This will add a workspace layout file to the file browser:

The next time you open JupyterLab, it’ll display everything the way it was when you last closed the program because it automatically updates workspaces as you change them. To return to a saved workspace, double-click on its file from the browser, and everything will reset to the way it was when you last saved it. When you make changes to a layout, choose File → Save Current Workspace to update your saved workspace.

Sharing Code Between Notebooks

If you need to perform lots of analysis in a notebook, there’s a danger that your notebook will become long and difficult to work with. Instead of creating a single large notebook, it’d be better to split your analysis down into separate notebooks. One way would be to duplicate your data, but this creates data management issues whenever your data changes. Fortunately, JupyterLab allows you to share data from one notebook with others.

Earlier you learned that the kernel is responsible for passing the code from a notebook to a console for running. Once the code has finished, the kernel returns its output back to your Jupyter Notebook for display. So, the kernel provides access to any data or functions that your program uses. By linking additional notebooks to the kernel of a notebook, its content becomes available to those additional notebooks.

Locate the cell in your Population Changes notebook that contains the Python population data lists that you copied earlier and delete it by clicking the trash can icon in the top-right corner of the cell. At this point, the notebook’s kernel will still hold the data. To fix this, choose Kernel → Restart Kernel → Clear Outputs of All Cells from the menu. This will reset your notebook. It’ll still contain its content, but not its output:

Now rerun the Population Changes cell that contains your calculate_differences() code and watch as it fails:

As you can see from the traceback, your code has raised a NameError. This has happened because your code can no longer find the population list that it needs. That’s because the list was removed from the kernel when you cleared it and is now unknown to your code.

To deal with this and make sure you use the same data source as your original Population Data notebook, you must share the kernel that Population Data is using with Population Changes. You can do this by selecting the Population Changes notebook and clicking the Switch kernel button in its top-right corner. From the dropdown, select the Population Data kernel as shown:

Now when you rerun all the cells in Population Changes, everything works as before. The population list is available once more.

If you like, you can experiment by changing the data in your Population Data notebook and rerunning both notebooks again. If you do, just remember to rerun the cell where you changed your data to update the shared kernel.

Checkpointing Your Notebook

When you work with a Jupyter Notebook, it automatically saves any changes that you make. However, it’s also possible to manually save a notebook. In the language of JupyterLab, this is called checkpointing, and you do it using Ctrl+S in Windows and Linux or Cmd+S in macOS. You can also click the Save and create checkpoint icon as shown:

When you first create a new notebook file, JupyterLab creates a file with an .ipynb file extension. In addition, it also creates a second .ipynb checkpoint file. This starts with the same name as the original notebook file, only with -checkpoint appended to it. This checkpoint file gets placed inside a hidden folder named .ipynb_checkpoints in the same folder as your original notebook.

By default, the initial notebook file and its checkpoint will be blank. When you add content to your notebook, the original notebook file gets automatically saved every two minutes. The checkpoint file remains untouched.

If you want to update the checkpoint file as well as the notebook file, then you do so by performing a manual save using Ctrl+S in Windows or Linux, Cmd+S in macOS, or File → Save Notebook from the menu. Doing this overwrites your previous checkpoint. If you then make changes to your notebook, JupyterLab autosaves them every two minutes, but again, the checkpoint is untouched.

Although autosaving is useful, it does mean that any incorrect changes that you make are also automatically saved. This is where checkpoints can help you. It’s possible to roll your notebook back to the last checkpoint by using File → Revert Notebook to Checkpoint….

To test this, add a new raw cell below the last cell of your Population Changes notebook and enter the text As you can see, the population has increased each decade. A raw cell contains completely unformatted and unformattable text. Now manually save the notebook to update its checkpoint:

Next double-click on your raw cell to edit it, and change this cell to read As you can see, the population has decreased slightly each decade. Wait at least two minutes then close your notebook without saving it, and shut down the server. Next restart the JupyterLab server once more. When you reopen your notebook, these changes should still be in it. If not, you haven’t waited long enough. Try again, but this time be more patient.

Now you realize you wish you hadn’t made this change. To revert back, select the File → Revert Notebook to Checkpoint menu option. When you’re asked to confirm, click the red Revert button. Now take a look at the cell that you changed:

As you can see, decreased has rolled back to increased. Thankfully, your invalid changes are gone.

The checkpointing feature within JupyterLab is fairly primitive. In essence, it offers you the capability to revert to the last manually saved version. You can only revert back to the last checkpoint, and once you’ve done so, you can’t roll back any further or even roll forward again. Before you perform a manual save, make sure your changes are safe for permanent saving. You can’t undo this if they’re not.

If you find that you’re making changes to your notebooks and want to retain earlier versions, the only way within JupyterLab is to create multiple versions of each file by using File → Save Notebook As and giving each a slightly different filename. Obviously, this could still leave you with version control issues.

Before you move on to some of the other features of JupyterLab, you’ll finish off by learning how to debug notebooks. This is something that you may not have seen, even if you’ve used Jupyter Notebooks before.

Debugging Your Notebook

JupyterLab uses the integrated debugger found within later versions of Jupyter Notebook. The integrated debugger allows you to perform common debugging tasks such as running code one line at a time to verify that it’s working the way you expect it to. You can also monitor the values of variables to make sure they contain what you expect them to.

As an example, you’ll run the debugger against your calculate_differences() function in your Population Changes notebook. Although this function works just fine, you’ll still use it to gain experience in operating the debugger.

To enable the integrated debugger inside your notebook, click the small bug icon in the top-right corner. The bug will turn orange to show that the integrated debugger is switched on:

With the debugger on, the debugger tab will be selected at the right of your screen. This tells you what your code is doing while it runs. The debugger contains various sections, including Variables, Callstack, and Breakpoints. Some of them will already be expanded, but they’re all collapsed for convenience here. Also, with the debugger switched on, each code cell gets line numbers. You can use these for reference during debugging.

Start off by running all the cells in your notebook. The quickest way to do this is to choose Run → Run All Cells from the menu. This will allow you to learn how the debugger displays the notebook’s variables.

Expand the variables section of the integrated debugger. Click the Table View icon, and you’ll see the complete set of variables that your notebook’s code uses, along with their current values:

Take a moment to look through the information on display. You can see the content of the various lists, the DataFrame, and even the zipped list that you used to create the DataFrame. This screen is one of the most important when using the debugger.

To see the debugger in action, you first of all clear everything from the notebook’s memory. To do this, you need to select Kernel → Restart Kernel and Clear Outputs From All Cells, then click Restart:

This will clear all outputs and variables from the notebook. If you now look at the list of variables, then you’ll see that you’ve cleared all of them. Each notebook has its own kernel, allowing you to clear each one independently of the others. In restarting the kernel, you’ve also disabled debugging.

Next, to see how to use the integrated debugger, you’ll debug your code. To begin with, enable the debugger once more and arrange the Variables, Callstack, and Breakpoints sections as shown. Also set a breakpoint by clicking on the margin next to your decades list as shown below:

You’ll see the breakpoint added to the Breakpoints section of the debugger. A small red dot appears next to the line to indicate that it has a breakpoint. Your code will run normally up to the breakpoint, and then it’ll enter debug mode. Once in debug mode, you can run the code at your own pace to monitor it. In this case, your entire code will run in debug mode because you’ve created a breakpoint at its first line.

To start debugging, make sure debugging is switched on, and then choose Run → Run All Cells from the menu. Your code will stop at the first breakpoint that it encounters, which will be highlighted:

Your notebook’s code has now paused processing and is awaiting your instruction on how it should proceed next. The choices are displayed visually in the bar above the callstack section of the debug window:

When you click on each of these icons, the program behaves slightly differently. As a starting point, consider the first three options:

• Continue will cause the rest of your code in the cell to run at normal speed, unless you’ve inserted a second breakpoint, in which case it’ll run normally to that breakpoint and then reenter debug mode.

• Terminate will immediately stop the code in the cell from running.

• Next will run the next line of code and then pause to await your further instruction. This is how you run an entire program one line at a time, automatically updating the variables section as each variable is populated. This is one of the most common operations that you use when debugging code.

To understand the debugger better, with the notebook still awaiting you instructions, select Next or tap F10. The code will progress to the next line and pause once more:

Pay particular attention to the variables section on the right, and you’ll see that the decades variable now has some data assigned to it. This has happened because line 6 ran successfully. By noting this information, you can verify that this line of code is working as expected.

Now tap F10 once more. As you might expect, the population variable now contains data. The program has moved to the top of the next cell containing your calculate_differences() function, and then it stops.

Now tap F10 once more, and control moves to the first line beyond the function. This is because only the line containing the function header has been processed. The function body can only run when your code calls it. In processing the header, your code now knows the function exists.

At this point, you have a choice to make. If you tap F10 again, you assign the population_variable its data, and the program ends. You may have expected the debugger to enter your calculate_differences() function and run through it. In fact, the function did run, but it did so at full speed. Selecting F10 runs a complete line of code at full speed, including any calls to functions. This is why the Next icon has an arrow jumping over a dot.

You can verify that the function has indeed run because if you look at the list of variables, you’ll see that population_change now has content:

As you can see, the population changes now show up in the population_change list.

Of course, there will be times when you need to run the debugger through the function code. To do this, tap the Terminate button in the callstack section or use Shift+F9. This will stop the debugger. Now restart the debugger and repeat the previous instructions until your notebook has stopped at the function call line. You’ll have tapped F10 three times to get there.

This time, instead of using F10, tap F11 or choose the Step In option in the callstack section instead. As its name and icon suggest, this will move into the code by entering the function’s body:

As you can see, the debugger now allows you to step through the function’s code, and it has stopped at the first line of the function’s body. Notice that the data_set variable, which only exists within the function, now contains data. Also, the callstack tells you that program control has left line 7 in the main module and entered line 2, which is in the calculate_differences() function. This information allows you to monitor the program’s flow.

Tap F10 a few times more until you’ve completed at least one iteration of the for loop. Keep an eye on the variables section, and you’ll see the variables change as the loop iterates. Again, you could run through the entire function one line at a time if you wanted to.

Once you’re satisfied that your function is working correctly, you can tap the Step Out button or use Shift+F11 to run the remainder of the function at normal speed and jump back to line 7, where you called it. Tap F10 once more, and this final line of code will run, completing the cell.

If you have the debugger switched on and don’t set any breakpoints, then running the code causes it to to run at normal speed. However, the debug window will still contain the value of every variable. This can be useful if you want to see what values your program is storing without printing.

Finally, you can remove an individual breakpoint by clicking on its red circle. The quickest way to switch all breakpoints off is by clicking the red bug symbol to switch debugging off and then clicking it again to switch debugging back on again.

While notebooks are by far the most commonly used component of JupyterLab, they’re not the only one. You’ll now turn your attention to some of its other interesting features.

Creating and Previewing a Markdown Document

To create a new Markdown file, make sure the Launcher page is displayed. If it’s not, then click any of the + symbols next to the tabs of any existing open content, and a new Launcher will appear. Then click the purple Markdown File icon:

You’ll now be looking at a blank Markdown file. Right-click its tab and rename it Handling Exceptions.md. Now it’s time to add content.

In this example, you’ll provide a short note that explains how Python can handle exceptions. This will allow you to practice some basic formatting. In addition, you’ll add some code and run it from within the Markdown file.

While Markdown isn’t terribly complicated, it’s still helpful to see what the formatted output will look like. Jupyter allows you to do this as you type the Markdown by displaying the Markdown preview. The preview automatically synchronizes with your Markdown file and lets you see what the final product will look like as you write it.

To open a Markdown preview, right-click on the blank Markdown file and choose Show Markdown Preview:

As you can see, a second preview window appears to the right of the Markdown file. It’ll be blank because you haven’t added any content to the Markdown file. You’ll fix this now and see another example of JupyterLab’s synchronization abilities. You decide to add the following to your Markdown file:

# Dealing With Exceptions

## What is an Exception?

An **Exception** gets **raised** when code encounters an occasional,
but not unexpected, error. Although exceptions are an unavoidable
part of software, because you are aware that exceptions may occur,
you should write code to deal with or **handle** them.
Unhandled exceptions will cause a program to crash.

## How Do You Handle Them?

You implement [*exception handling*](https://realpython.com/python-exceptions/)
to handle exceptions. In its most basic form, this provides both a *try*
and one or more *except* blocks:

* The *try* block contains the code you wish to monitor for exceptions.
Any exceptions raised within *try* will be eligible for handling.

* One or more *except* blocks are where you define code that will run
when exceptions occur and handle them. This is how you stop the exception
from crashing the code.

## What Are Some Common Exceptions

The Python language supports more than sixty common exceptions.
Two of the more common are:

| Exception             | Cause                                       |
|:----------------------|:--------------------------------------------|
| **ZeroDivisionError** | Raised when you attempt to divide by zero   |
| **ValueError**        | Raised when you pass an inappropriate value |

## Example

```python
try:
    first_number = float(input("Enter your first number"))
    second_number = float(input("Enter your second number"))
    print(f"{first_number} / {second_number} = {first_number / second_number}")
except ZeroDivisionError:
    print("You can't divide by zero")
except ValueError:
    print("You must supply a number")
```                                                                                      .

Don’t worry if some of these characters look odd to you. You’ll learn what they mean below. In the meantime, if you’ve typed everything in correctly, then your Markdown and preview will look like this:

If you notice any differences between your output and what’s shown above, then go back and check your Markdown source carefully.

Here’s how you used Markdown symbols:

• To create headings, you used one or more # characters. A single # produces a heading, while ## produces a subheading.
• To make your text bold, you surrounded it with **. To italicize your text, you surrounded it with *.
• To create hyperlinks, you enclosed the link text in [] and the URL in (). In your Markdown, clicking the exception handling link text will take your readers to a tutorial on the subject.
• To create the table, you separated its data with | and used :- to specify left alignment.
• To define a code block, you wrote its code between triple backticks (```) followed by the word python, and you put another set of triple backticks at the end of the code block. This not only formats it neatly but also allows you to run the code by clicking inside the box.

As you can see, you can quickly create a neatly formatted document using a few common pieces of Markdown syntax. These will most likely meet most of your needs, but more involved formatting options are available if you need them. However, writing Markdown isn’t the only thing you can do with your Markdown files in JupyterLab.

Running Code Embedded Within a Markdown File

Although basic Markdown is good for providing information about program code, JupyterLab goes a step further and allows you to run the code embedded within it. This is a great way of ensuring that your code does what you expect it to.

If you want to run your code from a code block, then you need to create a console for it to run in. To do this, right-click anywhere in your Markdown file and choose Create Console for Editor from the menu. You must then choose a kernel. Unless you need to access data stored in an existing kernel, selecting Python3 (ipykernel) will link in the new kernel to manage the running of the code in the new console window that has appeared:

Now that you’ve created a console and linked a kernel to your Markdown file, you can run the code. To actually run the code, you put your cursor anywhere inside the Python block—for example, to the left of the first except keyword—and then tap Shift+Enter to run it:

As you can see, the code gets passed to the console and runs. In this test case, the zero that you entered as the second input caused your code to raise and handle a ZeroDivisionError. Feel free to run the cell once more, but this time, enter "ten" as the first input and see how your code reacts.

One of the other cool things that JupyterLab allows you to do is to run small snippets of your code. This can be useful if you’re analyzing a specific part of it. To do this, select the lines of code that you want to run and tap Shift+Enter to run that portion:

This time, you only selected lines 28 through 33. When you tapped Shift+Enter, only those lines ran. When you entered an invalid value for one of the numbers, a ValueError got raised but remained unhandled because you didn’t select the handler for it in lines 34 and 35.

Although this is a useful feature, be careful when selecting small parts of your code. You need to make sure that you select enough to form a complete program. For example, selecting lines 32 and 33 alone will cause a crash because the selected code is a syntax error by itself.

As you can see, JupyterLab allows you to write Markdown files that contain code that you can document and run. So not only can you view your Markdown the way you want your readers to see it, but by attaching a console to your Markdown file, you can test your code as well. That means you can avoid creating Markdown documents with incorrect code.

Using a Table of Contents With a Markdown File

As a convenience, if you have a long Markdown file, you can jump to specific sections within it by generating a table of contents. To do this, click the Table of Contents icon as shown:

If you select the Markdown file preview then click any of the table of contents entries, then your Markdown preview file will jump to that heading. Similarly, if you select the Markdown file first, then it’ll jump to the position that you select from the table of contents.