Execution

Execution Target

Scripton displays the active execution target in the toolbar:

• This is the script that will be run by default when you either click on the ▶ button in the toolbar, press ⌘ + R, or enter /run in the REPL.

• By default, Scripton automatically switches the current execution target to the currently focused script tab. If, instead, you want to fix/freeze the execution target to a particular script, you can do so by clicking on the Pin button next to it.

• Alternatively, you can also run and pin scripts by right clicking on their tab and using the context menu.

• The toolbar dropdown lets you quickly access recently run scripts.

Auto Python Relaunch

Scripton automatically launches new instances of the Python interpreter process —

• If you're entering code in the REPL, the last launched Python interpreter and its state is used. This is similar to how the standard Python REPL (or Python Notebooks) behave.

• Whenever you run a script, a new Python process is automatically created and used. This is similar to launching a Python script from a terminal. This guarantees no state creeps across executions (unlike, say, Python Notebook cell executions).

• In the figure above, note that when a script finishes running, it leaves the Python process alive until the next script execution. This allows the REPL to interact with any global state available after execution.

• If desired, you can always manually restart the Python interpreter from the REPL by using the /restart special command.

Iterrupting Execution

• You can interrupt execution via the keyboard shortcut CTRL + C, or by clicking the Stop button in the toolbar:

• The initial request to stop execution transmits a SIGINT signal to the Python process (typically raised as a KeyboardInterrupt exception in Python). If for any reason the Python process is unresposive to this initial interruption attempt, Scripton enables more drastic measures after a brief delay. This is indicated by the stop button switching to an axe icon as shown below. Interruption attempts after this point transmit a SIGKILL signal.

The /run command

The /run special command can be used in the REPL to execute Python scripts.

• When used without any arguments, the /run command executes the currently active execution target (displayed at the center in the toolbar). The resolved execution target is also specified near the right edge —

• An optional argument may specify a Python script path. This may either be a workspace relative path:

  /run tools/plot_confusion_matrix.py

  or an absolute path:

  /run /Volumes/work/tau_zero/accelerate.py

• Arguments may be passed to the script by specifying them after the path:

  /run visualize_depth_map.py --src /data/primesense --tag "version 2"

  The propagated arguments match the Python standard library's shlex.split parsing.

• By default, using /run <script> is similar to invoking python <script>. However, there may be cases where the behavior of python -m <script> is desired instead. That can be achieved by using the /run module:<...> syntax as described in the Run as Module section.

The /execute command

This is nearly identical to the /run command, with the sole exception that all breakpoints are disabled for this execution. This provides a quick way to run the script without any debugging overhead.

The /restart command

Starts a fresh instance of the Python interpreter. You typically don't need to do this as Scripton will automatically start a new instance for each script run (as described in more detail in the execution section)

Run as Module

Scripton automatically detects when an open file is part of a Python packages based on the presence of __init__.py files. When executing these modules, it behaves similar to the python -m command —

This auto-detection can be disabled either via the execution menu (as shown above) or in Settings. When disabled, these package constituents are treated the same as regular scripts.

You can also explicitly invoke a python -m style execution using the /run module: command:

If the optional path prefix is omitted, the given module is expected to be at the top-level of the open workspace.

For instance, the following command assumes foo/bar.py (or foo/bar/__main__.py) exists at the top-level of the currently open workspace:

and is equivalent to running python -m foo.bar from the workspace root.

If, instead, the package foo was located under, say, work/source, you'd use: