Starting an Interactive REPL

By most measures, the simplest way to run Python code is to type it at Python’s interactive command line, sometimes called the interactive prompt, and often more concisely labeled the REPL (which stands for read–eval–print loop).

There are a variety of ways to start this command line—in a coding GUI or app, in a web notebook, from a system console, and so on. Assuming Python is installed locally as an executable program on your device, the most platform-neutral way to start an interactive interpreter session is to simply type a Python command at your device’s console prompt, without any arguments. Since this is most common, nearly universal, and arguably simplest, let’s start here.

Despite this scheme’s generality, both the Python command you’ll type, and where you’ll type it, varies per platform. On Windows, macOS, and Android, for example, py, python3, and python, respectively, do the job as follows:

$ py
Python 3.12.3 (…etc…, Apr  9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z

$ python3
Python 3.12.2 (…etc…, Feb  6 2024, 17:02:06) [Clang 13.0.0…)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

$ python
Python 3.11.4 (…etc…, Jul  2 2023, 11:17:00) [Clang 14.0.7…)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

A python3 works on Android and Linux, too, if you want to narrow this to one exception—for Windows’ py. This book uses python3 in platform-neutral examples just because it works almost everywhere; use py instead if you’re working on Windows (python3 works on Windows, too, but is reserved for a lesser Store install today: see Appendix A). Also per that appendix, all these commands must be on your system search path (generally known as PATH) and require a full pathname if they’re not, but most installs set this up automatically.

Typing a Python command at your system prompt like this begins an interactive Python session (i.e., REPL). The $ character at the start of listings here stands for a generic system prompt on all platforms throughout this book—it will likely vary on your device and is not input that you type yourself. On Windows, a Ctrl+Z key combo (followed by Enter) ends this session as shown; on Unix (which includes macOS, Linux, and Android), it’s Ctrl+D instead.

You’ll notice that the interactive prompt opens with a message that identifies the Python being used (e.g., “3.12.3” is Python 3.12) and the platform it’s running on (e.g., “win32” for Windows, “darwin” for macOS, and “linux” for both Linux and Android), followed by a line with tips for more info. We’re going to omit these opening lines in this book, except where they’re helpful.

The notion of a system prompt (a.k.a. shell or console) where you type the Python command is generic, but exactly how you access it varies by platform. It might be Command Prompt or PowerShell on Windows; Terminal on macOS and Linux; the Termux app on Android; or a dedicated terminal screen in some apps like Pydroid 3.

On most platforms, you can also start an interactive session in ways that don’t require typing a command at all, but they vary even more widely. On Windows, for example, a Start-menu option opens a similar REPL, as do the IDLE GUI on all PCs, dedicated screens in apps on Android and iOS, and some web-browser interfaces. We’ll cover some of these options ahead, but see Appendix A for more platform tips, and the web for more help with other options.

Anywhere you see the >>> prompt, though, you’re in an interactive Python session and REPL—you can type any Python statement or expression here and run it immediately by simply pressing the enter key (or similar button). We will do so in a moment, but first we need to get a few admin details sorted out to make sure all readers are set to go.

Where to Run: Code Folders

Now that you’re starting to learn how to run code, you’ll also need to know where to run code. You can save and run code anywhere you can make files, but this book has two recommendations for using its examples, especially for newcomers:

Work in a dedicated code folder

To avoid stomping on other content, run this book’s examples from a dedicated code folder (a.k.a. directory) on your device. For instance, this book runs all its code in a folder nested in the user account (or “home”) folder on each device. Your code folder can be located wherever you like and called whatever you wish, but running out of one folder will help you keep track of your work and simplify some tasks.

Work in per-chapter subfolders of your code folder

To avoid clutter and filename collisions, also organize your code into per-chapter subfolders, nested in your dedicated code folder. Per-chapter subfolders will ensure that imports in examples will work without advanced settings (that you’ll learn later). There’s more on imports and directories in an upcoming note. For now, keep in mind that console commands in this book will implicitly be run in a per-chapter subfolder of a dedicated code folder on the host. The folder name will normally be omitted for platform neutrality and is irrelevant to the code.

If you’ll be using this book’s examples package, it’s already done the setup work for you. For example, unzipping the examples creates a code folder named LP6E, whose Chapter03 subfolder has this chapter’s code. If you’ll be using this package to avoid typing code or copying from emedia, simply run its examples in the subfolder of the chapter you’re studying. This is where REPLs will be started and where script files will be run. As you’ll learn later, this is also where data files that our scripts create will show up, unless scripts use filenames with explicit folder paths.

If you’ll be creating code on your own, you should probably create a similar code directory structure of your own before we move on. On PCs, use your system’s file explorer, or run a command line: mkdir folder works on Windows and Unix. On Android, you can also use a file explorer (or mkdir in Termux), but be sure to pick a folder accessible to your Python app. Some coding interfaces may offer other ways to create folders; see your tool for info.

Once your per-chapter code folders are set to go, always start there to write, save, and run the examples in this book. How you’ll do this depends on your usage mode. In consoles, a portable cd folder command changes directories. In a GUI like IDLE, opening and running a file may go to its folder. And in other interfaces, you might launch a REPL for a file in the UI or use other schemes too varied to cover here. As a fallback, Python’s os.getcwd() you’ll meet shortly shows the current directory and its os.chdir('path') changes it—as long as you import os first.

What Not to Type: Prompts and Comments

Speaking of commands, remember not to type the $ character used at the start of this book’s command lines to denote a system console prompt; type just the text after these prompts. This may sound simple to experienced programmers, but it’s a very common first error for beginners, and we’re not excluding anyone here.

Similarly, do not type the >>> and ... prompt characters shown at the start of lines in interpreter interaction listings and used by this book to denote code run in a REPL; type just the text after these prompts. These are prompts that Python’s standard REPL displays automatically as visual guides for interactive code entry and may or may not appear in your interface. For instance, the ... prompt is used for continuation lines in some REPLs, but is just a label in IDLE, and is omitted by some of this book’s listings for easier copy/paste; either way, don’t type it yourself.

To help you remember this, user inputs you must type are shown in bold in this book, and prompts are not. Also keep in mind that commands typed after these system and Python prompts are meant to be run immediately and are not generally intended to be saved in the source files we will be creating; you’ll see why this distinction matters ahead.

In the same vein, you normally don’t need to type text that starts with a # character in this book’s code listings—as you’ll learn later, these are comments, not executable code. Except when # is used to introduce a #! directive at the top of a script, you can safely omit it and the rest of the line that follows it (there’s more about #! in Appendix A).

Other Python REPLs

Having said all that, you should also know that Python REPLs can also be had in systems that convolute the traditional model covered in this chapter. IPython, for example, provides an alternative, separately installed, and enhanced Python interactive session, which labels commands by number and doesn’t use >>> prompts. Jupyter notebooks provide the IPython REPL, too, and run it in a web browser instead of system console (we’ll explore Jupyter later in this chapter).

To muddy this story further, the PyPy system of Chapter 2 uses >>>> for its REPL prompts to distinguish it from CPython’s ternary >>> (though you may have to look hard to tell); the IDLE GUI covered ahead displays >>> off to the side (and not in a system console); smartphone apps may vary too (see Appendix A); and the interactive prompt can technically be changed to anything (it’s sys.ps1 to your code, and can be set in a startup file, per Python docs).

All of which means that your Python interactive session may differ from the mainstream model that this chapter often employs. Depending on your tools and goals, you might see a different prompt or none at all, and you might type interactive Python code into a web browser, GUI, or app instead of the system console.

In general, though, this book recommends the traditional and simpler options it demos and covers, when you’re first starting out. IPython and Jupyter, for example, have learning curves of their own, and Jupyter is geared toward scientific work, which is just one of many Python roles. If and when you opt to use alternative coding interfaces like these, and others sure to arise in the future, extrapolate to their REPLs’ minor differences as needed.

Running Code Interactively

With those preliminaries out of the way, let’s move on to typing some actual code. However it’s started, the Python interactive session begins by printing some informational text (again, mostly omitted hereafter), then prompts for input with >>> (or similar) when it’s waiting for you to type a new Python statement or expression.

When working interactively, the results of your code are displayed below the >>> input lines after you press the Enter key (or similar). For instance, here are the results of two Python print statements:

$ python3
>>> print('Hello world!')
Hello world!
>>> print(2 ** 8)
256

There it is—we’ve just run some Python code (it’s not much, but it proves the point). We’re still skipping most code details for now, but in brief, print is a built-in tool that sends a line displaying whatever you pass to it, to wherever you’re working; because it’s a function call in Python, the parentheses in this code are required. We’ve used it here to display a Python string and an integer, as shown by the output lines that appear after each >>> input line.

When coding interactively like this, you can type as many Python commands as you like; each is run immediately after it’s entered. Moreover, because the interactive session automatically prints the results of expressions you type, you don’t usually need to say “print” explicitly at this prompt; the format of the following automatic displays can differ slightly from print, but it’s not yet important to know how:

>>> language = 'Python'
>>> language
'Python'
>>> 2 ** 8
256
>>> ^Z                     # Use Ctrl-D (on Unix) or Ctrl-Z (on Windows) to exit
$

Here, the first line saves a value by assigning it to a variable (language), which is created by the = assignment; and the last two lines typed are expressions (language and 2 ** 8), whose results are displayed automatically. Again, to exit an interactive session like this and return to your system prompt, type Ctrl+D on Unix-like machines, and Ctrl+Z on Windows. In the IDLE GUI discussed later, either type Ctrl+D everywhere, or simply close the window.

Notice the italicized note about this on the right side of this listing—starting with # here. This book uses these throughout to add remarks about what is being illustrated, but you don’t need to type this text yourself; if you do, they’re ignored by Python as comments. In fact, much like system $ and Python >>> prompts, you shouldn’t type this when it’s on a system command line; the #… part is ignored by Python but may be an error in system shells.

Now, we didn’t do much in this session’s code—just typed some Python print and assignment statements, along with a few expressions, all of which we’ll study in detail later. The main thing to notice is that the Python REPL executes the code entered on each line immediately, when the Enter key (or similar) is pressed.

For example, when we typed the first print statement at the >>> prompt, the output (a Python string) was echoed back right away. There was no need to create a source code file, and no need to run the code through a compiler and linker first, as you’d normally do when using a language such as C or C++. Strictly speaking, interactive code is compiled to bytecode in memory and run by the PVM in CPython (see Chapter 2), but you don’t need to care.

As you’ll see in later chapters, you can also run multiline statements (e.g., for loops) at the interactive prompt; such a statement may prompt for continuation lines with ... as noted earlier and runs immediately after you’ve entered all of its lines and pressed Enter twice to add a blank line. Blank lines aren’t required (and are ignored) in code files, but needed to let some REPLs know your statements are complete. Also, bear in mind that the current and standard REPL runs just one statement at a time—don’t paste large code blocks at its prompt!

Why the Interactive Prompt?

The interactive prompt runs code and echoes results as you go, but it doesn’t save your code in a file. Although this means you won’t do the bulk of your real-world coding in interactive sessions, the interactive prompt turns out to be a great place to both learn the language and test program files on the fly. Here’s a quick rundown of these roles.

$ python3
>>> 'Hack!' * 8                                  # Learning by trying
'Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!'

>>> X                                            # Making mistakes is OK
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'X' is not defined

>>> sys.ps1                                      # Requires "import sys"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sys' is not defined. Did you forget to import 'sys'?

>>> import os
>>> os.getcwd()                                  # Testing on the fly
'/Users/me/code'

A First Script

Let’s get started. Open your favorite text editor, type or copy/paste the statements in Example 3-1 into a new text file named script1.py and save it in your working code directory that you set up earlier (make it now if you skipped over that step). Any editor will work, including vi, Notepad, a smartphone app’s editor, and the IDLE GUI coming up soon. You can also find this file in the book examples package, but typing code is an important exercise early on.

# A first Python script
import sys                  # Load a library module
print(sys.platform)
print(2 ** 100)             # Raise 2 to a power
x = 'Hack!'
print(x * 8)                # String repetition

This file is our first official Python script (not counting the two-liner in Chapter 2). You shouldn’t worry too much about this file’s contents just yet, but as a brief description, its code:

• Imports a Python module (libraries of additional tools) to fetch the name of the platform

• Runs three print function calls to display the script’s results

• Uses a variable named x, created when it’s assigned, to hold onto a string object

• Applies various object operations that we’ll begin exploring in the next chapter

The sys.platform here is just a string that identifies the kind of computer you’re working on; it lives in a Python module called sys (part of its standard library), which you must import to load (again, more on imports later). Also notice how this file uses explicit print calls; unlike the REPL, output in files is never automatic, so you must say print in files to see their output (and forgetting this is a regular first mistake, but at least you’ve been warned!).

For color, this file adds some Python comments—the text after the # characters. These were mentioned earlier, but should be more formal now that they’re showing up in scripts. Comments can show up on lines by themselves, or to the right of code on a line. The text after a # is simply ignored as a human-readable note and is not considered part of the statement’s syntax. If you’re copying this code, you can ignore the comments; they are just informative. This book uses a different formatting style to make comments more visually distinctive, but they’ll be normal text in your code.

Again, don’t focus on the syntax of the code in this file for now; you’ll learn about all of it later. The main point to notice is that you’ve typed this code into a file, rather than at the interactive prompt. In the process, you’ve coded a fully functional Python script.

Notice, though, that the module file is named script1.py. As for all top-level files (i.e., files run directly), it could also be named simply script1, but files of code you want to import in another file or REPL have to end with a .py suffix. Because you may want to import them in the future, it’s a good idea to use .py suffixes for most Python files that you code. Also, some text editors and file explorers detect Python files by their .py suffix; if the suffix is not present, you may not get features like syntax colorization and automatic indentation in editors or tap-to-run in explorers.

Running Files with Command Lines

Once you’ve saved the preceding section’s text file, you can ask Python to run it by listing its full filename as the first argument to a Python command—like the following typed at the system shell’s $ prompt on a Unix device (but don’t type this at a Python REPL prompt, and read on to the next paragraph if this doesn’t work right away for you):

$ python3 script1.py
darwin
1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!

Just as for starting the REPL we studied earlier, the command name may vary (e.g., use py instead of python3 on Windows, usually), and you can type such a command in whatever your system provides for command-line entry—Command Prompt on Windows, Terminal on macOS, or the Termux app on Android, among others. You might also run this code file with a dedicated run button in a GUI, app, or browser-based UI, but we’ll postpone such options until later in this chapter (see also Appendix A for all things platform specific).

Be sure to run your Python command in the same working directory where you’ve saved your script file (cd there first if needed), and run it at the system prompt, not Python’s >>> prompt. Also like starting the REPL, you may have to replace the command’s first word with a full directory path if Python isn’t on your PATH setting, but most installs automatically ensure that it is (see Appendix A for more on Python installs and PATH).

If all works as planned, this shell command (or similar) makes Python run the code in this file line by line, and you will see the output of the script’s three print statements—the name of the underlying platform as known to Python, 2 raised to the power 100, and the result of the same string repetition expression we saw earlier (there’s more on the meaning of the last two of these in Part II).

If all didn’t work as planned, you’ll get an error message—make sure you’ve entered the code in your file exactly as shown, and try again. We’ll talk about debugging options in the sidebar “Debugging Python Code,” but at this point in the book your best bet is probably rote imitation. And if all else fails, you might also try running under the IDLE GUI discussed ahead—a tool that sugarcoats some launching details, though sometimes at the expense of the more explicit control you have when using command lines.

If copying code grows too tedious or error-prone, you can also fetch this book’s examples on the web, though again, typing code initially will help you learn to avoid syntax errors. See the Preface for info on obtaining the examples.

Command-Line Usage Variations

When you type a command to run a Python code file, the command you type is run by a system shell program (e.g., Bash on Unix). Because of this, all of the shell’s syntax is available for more custom runs. For instance, you can route the printed output of a Python script to a file to save it for later use or inspection, by using special shell syntax:

$ python3 script1.py > saveit.txt

In this case, the three output lines shown in the prior run are stored in the file saveit.txt instead of being printed. This is generally known as stream redirection; it works for both output (>) and input (<) text and is available on Windows and Unix-like systems. This is useful for testing, as you can write programs that watch for changes in other programs’ outputs. It also has little to do with Python, though (Python simply supports it), so we will skip further details on shell redirection syntax here. Redirection is for command lines only, though, because it’s a function of the system shell.

On Windows, you can also type just the name of your script and omit the name of Python itself. Because Windows uses filename associations to find a program with which to run a file, the file’s name is enough to run a .py file. The following command, for example, will automatically be run by Python on Windows (technically, by Python’s py Windows launcher described in Appendix A):

$ script1.py

This works just as though you had clicked on the file’s icon in File Explorer (a launch mode covered later). One fine point here: Command Prompt runs programs this way in its own window, but PowerShell may not; use py to view unredirected output in the latter if needed (or use the icon-click input() trick also coming up).

Finally, remember to give the full path to your script file if it lives in a different directory than the one in which you are working. For example, the py Python command in the following, run in PowerShell on Windows, assumes Python is in your system path but runs a file located elsewhere:

PS C:\Users\me\code> cd D:\temp\savecode               # Go to a different folder
PS D:\temp\savecode> py C:\Users\me\code\script1.py    # Run a script elsewhere
win32
1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!

If your PATH doesn’t include Python’s directory, and neither Python nor your script file is in the directory you’re working in, use full paths for both—like the following on macOS, which for good measure throws in output stream redirection to a file located outside the current working directory (where you are when this command is run):

$ /usr/local/bin/python3 /Users/me/code/script1.py > /Users/me/data/saveit.py

This is a lot to type, but also pathological and atypical. To keep your commands simpler than this, make sure Python is on your PATH, and cd to script or data folders first. Again, most installs setup PATH automatically, so you need only focus on script and data folders when running commands.

Clicking and Tapping File Icons

On most PC platforms, Python program files can be run by simply clicking or tapping their filename or icon in the local file explorer. For example, this works automatically on Windows in File Explorer, thanks to filename associations set up during Python’s install. Clicks also run code files on macOS in Finder, if made to Open With the Python Launcher included in the macOS install; drags to the Python Launcher app when available work the same as clicks.

The file-clicks story is more involved on Linux, where files likely need executable permission and a #! first line to name Python. On smartphones, tapping a filename in a file explorer on Android (or Files on iOS) may open the file in an associated Python app, but this may work only for some explorer/app combos, and may not give access to all of a program’s files in some contexts. For more insight, consult your platform and app docs, or experiment on your device.

Also see Appendix A for more info. As noted there, Windows and Linux clicks don’t keep the window open for viewing output and error messages after programs end: if a script just prints and exits, it, well, just prints and exits—the console window appears, and text is printed there, but the console window closes and disappears on program exit. Per Appendix A, coding a closing call to Python’s input() forces a pause before exit so you can see output, but this doesn’t help for error messages. Use other run techniques when this matters.

The IDLE Graphical User Interface

So far, we’ve seen how to run Python code with interactive sessions, system command lines, and icon clicks. If you’re looking for something a bit more visual, IDLE provides a GUI for Python programming, and it’s a standard and free part of the Python system. IDLE is usually referred to as an integrated development environment (IDE), because it binds together multiple development tasks into a single view.

In short, IDLE lets you edit, run, browse, and debug Python programs, all from the same GUI. Because it’s coded in Python with the tkinter GUI toolkit, it runs portably on all Python PC platforms—Windows, macOS, and Linux. For many, IDLE represents an easy-to-use alternative to typing command lines, a less problem-prone alternative to clicking on icons, and a great way for newcomers to get started editing and running code. You’ll sacrifice some control in the bargain, but this typically becomes important only later in your Python career.

IDLE install and startup are covered in Appendix A, so we won’t repeat the full details here. In brief, it’s standard with the python.org Python installers for Windows and macOS and can be had separately in Linux repositories. Once installed, it can be launched with the usual suspects: Start on Windows, Launchpad or Finder on macOS, a command line on Linux, and file right-clicks where supported.

Appendix A also has screenshots that capture IDLE in action on each platform, but Figure 3-1 captures its dark theme on Windows for both variety and a quicker look; as it demos, after running this chapter’s script1.py from Example 3-1 in the edit window on top, its output appears in the interactive Shell window.

Figure 3-1. IDLE with its dark theme on Windows

Tip: because IDLE is just a Python script on the module search path in the standard library, you can also generally run it on any platform and from any directory by typing the following Python command in a system console window (use py instead of python3 on Windows, as usual). Python’s –m flag simply locates a module using the normal import search, but runs it as a top-level script (Part V covers both this search, and the “.” package syntax required here):

$ python3 -m idlelib.idle         # Find and run idle.py in a package folder

Once IDLE is started, its usage is straightforward and documented in its in-program Help. In brief, the Shell window provides the usual interactive REPL with command recall, and each edit window allows you to view, modify, and run a file of code. The Shell’s File→New File and File→Open… start and open code files. Edit windows’ Run→Run Module runs code in the window where it’s selected, and Run→Run… Customized supports passing command-line arguments to scripts (which is out of scope here and not a full system shell, but useful for scripts that expect these).

IDLE has many more features, but as a sampler: it also does tab completions, pop-up balloon help for functions, and object attribute lists as you type code, and includes an object browser and GUI debugger. To use IDLE’s debugger, enable it in the Debug menu, set breakpoints by right-clicks in edit windows, and run. For simpler debugging needs, right-click on the text of any error message in the Shell window to jump to the line of code where the error occurred.

For more IDLE tips, see this book’s Appendix A, IDLE’s own Help menu, and the notes for your platform in “Python Setup and Usage” in Python’s standard manuals. Like most GUIs, the best way to learn IDLE may be to test-drive it for yourself. At the end of the day, its usability may be essential for some beginners, but it comes with an extra learning curve, is not as flexible as command lines, and adds sugarcoating that might be a negative when your programming needs outgrow its scope. As always, vet for yourself on a PC near you.

Other IDEs for Python

Because IDLE is free, portable, and a standard part of Python, it’s a nice first development tool to become familiar with if you want to use an IDE at all. There are, however, a handful of alternative IDEs for Python developers, some of which are substantially more powerful and robust than IDLE.

Among these, PyCharm, PyDev, Wing, VSCode, Spyder, and PyScripter all come with the usual edit-and-run GUIs, but some add additional and advanced tools such as code refactoring and source-control integration. These IDEs also have major learning curves and are not recommended for most Python beginners. Still, you may wish to file this away for later in your Python career when you’ve mastered the language and move on to industrial-strength development.

Smartphone Apps

If you’re running this book’s examples on an Android or iOS smartphone or tablet, you’ll be using an app. Some, like Termux on Android, come with a traditional command line and support all the REPL and file commands we’ve seen. In others, though, you’ll launch code files with devices in the app’s user interface (e.g., button taps), instead of traditional command lines. This isn’t much different in spirit from running code in IDLE or other IDEs, but because details vary per app, see Appendix A for mobile platform tips, as well as your app’s docs for more info.

WebAssembly for Browsers

Although an emerging technology, it’s also possible to run Python code in web browsers. This is enabled today by WebAssembly (a.k.a. Wasm), which defines a portable bytecode format that is run by web browsers, much as the Python PVM runs its own bytecode (see Chapter 2). By compiling the Python interpreter’s source code to this format with tools like the Emscripten LLVM-based compiler, web browsers are able to run Python, and hence your Python programs. While other Python-in-the-browser initiatives of the past have largely fizzled, WebAssembly is standardized by the World Wide Web Consortium (W3C) and already supported by all major desktop and mobile web browsers.

Compiling Python itself to Wasm is not trivial (and far too much to ask of Python beginners), but the Pyodide system has already done most of the work for you: it’s a port of CPython to the WebAssembly/Emscripten platform compiled and ready to run, with JavaScript integration for access to the browser Document Object Model (DOM) and web APIs. To use Pyodide in a web page, you’ll load it from a server and initialize it in a browser, with an HTML document that uses provided JavaScript code and API tools. The end result can run many Python programs in web browsers, with no local installs required.

The chief downsides of this model seem to be speed and utility. Downloading a compiled CPython interpreter to run a Python script in a browser is not quick, and the speed of Python scripts in this context may vary. Moreover, Pyodide comes with a fixed set of Python tools, and Python scripts run by browsers live in a sandbox with limited access to tools and resources on the host device. Persistent storage, for example, may support POSIX file calls and paths, but is virtual and ultimately limited in this context to options supported by browsers.

Hence, while this option may avoid some Python installs and open possibilities for Python on the web, it’s not as useful for general software development as others, and its future is impossible to predict. Watch the web for more on this evolving story—including the alternative MicroPython for Wasm, which is smaller than CPython but implements a constrained Python subset per Chapter 2, and the py2wasm Python-to-Wasm compiler, announced just as this book was being written.

Jupyter Notebooks for Science

We met this option earlier in conjunction with REPLs. Jupyter is a set of tools that allow Python code to be run in web browsers, with a focus on supporting scientific-programming tasks. Its primary and classic tools require a server to be separately installed and launched to run the code you enter in a web page, but it also comes in a form that runs code locally in browsers using the WebAssembly and Pyodide systems described in the preceding section. In both forms, Jupyter pages follow a flexible notebook paradigm, with interactive coding using the IPython REPL we also met earlier, code cells that run with a button click, visualization using Python numeric tools, and more.

While Jupyter is a useful and popular tool in many STEM roles, it’s not targeted at general-purpose software development and isn’t as broadly applicable as traditional tools like command lines stressed in this book. See other resources for usage details if Jupyter notebooks may be a part of your Python coding future.

Ahead-of-Time Compilers for Speed

Also per Chapter 2, a number of AOT compiler systems, including Nuitka and Shed Skin, compile Python programs all the way to machine code, much like C and C++ compilers. Once you install such a system, you’ll run its compiler on a file of Python code first, and then run the resulting program like any other executable. AOT compilers can boost program speed but add extra development steps that slow the programming process substantially, and negate some of the advantage of using Python. Especially for Python newcomers, these systems are probably best explored after learning the Python language using more accessible options, like traditional REPLs, IDEs, and command lines.

Running Code in Code

This chapter has talked about “importing modules” a few times without really explaining what this term means. We’ll study modules and larger program architecture in depth in Part V, but because imports are also a way to launch programs, this section will introduce enough module basics to get you started. Like imports, the Python exec built-in can be used to launch files in code too, and tools in standard-library modules let you launch programs with command lines. While we can’t go into full detail in this chapter, this section briefly surveys the launchers in this department.

$ python3
>>> import script1
darwin

1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!

>>> import script1
>>> import script1

>>> from importlib import reload
>>> reload(script1)
darwin
1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!
<module 'script1' from '/Users/me/Code/script1.py'>

title = 'Learning Python, 6th Edition'

$ python3                          # Start Python REPL
>>> import myfile                  # Run file, load module as a whole
>>> myfile.title                   # Use its attribute names: '.' to qualify
'Learning Python, 6th Edition'

$ python3                          # Restart Python REPL
>>> from myfile import title         # Run file, copy its names
>>> title                          # Use name directly: no need to qualify
'Learning Python, 6th Edition'

a = 'PC'                       # Define three attributes
b = 'Phone'                    # Exported to other files
c = 'Tablet'
print(a, b, c)                 # Also used as variables in this file

$ python3 threenames.py
PC Phone Tablet

$ python3
>>> import threenames                    # Grab the whole module: it runs here
PC Phone Tablet

>>> threenames.b, threenames.c           # Access its attributes: qualify to use
('Phone', 'Tablet')

>>> from threenames import b, c          # Copy multiple names out: use directly
>>> b, c
('Phone', 'Tablet')

$ python3
>>> exec(open('script1.py').read())
darwin
1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!

>>> x = 999
>>> exec(open('script1.py').read())    # Code run in this namespace by default
…same output…
>>> x                                  # Its assignments can overwrite names here
'Hack!'

$ python3
>>> import os
>>> os.system('python3 script1.py')
darwin
1267650600228229401496703205376
Hack!Hack!Hack!Hack!Hack!Hack!Hack!Hack!
0

Other Launch Options

You’ve already seen a blizzard of code-launching options for Python, but this accounting is still incomplete. For example, Python code can also be run today by:

• Programs written in C, C++, Java, and more, which embed Python and Python code

• Text editors that aren’t full IDEs, but know how to run Python code you’re editing

• Excel spreadsheets, when calculating a sheet’s cells coded in Python

• Web servers that spawn scripts automatically in response to browser UI actions

• Users launching standalone executables, which we explored in Chapter 2

• And (as usual) more

Moreover, launching techniques tend to evolve as rapidly as everything else in computing, and future options are impossible to foresee. In general, because Python keeps pace with such changes, you should be able to launch Python programs in whatever way makes sense for the machines you use, both now and in the future—be that by swiping on your smartphone, grabbing icons in a virtual reality, or shouting a script’s name over your coworkers’ conversations.