Script Execution

The "Run" Mechanism

Script mode is optimized for executing full files. When you click the green Run button (or press Ctrl + Enter), Python Online initiates a sequence of steps to ensure your code executes safely and accurately on our servers.

In a multi-tabbed IDE, you might be looking at the Output log, analyzing a CSV data file, or configuring a JSON file when you decide to hit "Run". It would be frustrating if the engine tried to execute a JSON file as Python code.

To solve this, the execution engine uses Smart File Tracking. The IDE constantly tracks the last active Python file you touched. If you select script.py, then switch tabs to read data.csv, hitting the Run button will intelligently trigger script.py in the background.

Under the Hood: The Execution Shim

Your script is not run entirely "raw". Before execution, the backend injects your code into an isolated container and runs it through a transparent wrapper file called the Execution Shim.

This shim performs several critical platform functions invisibly:

• Path Resolution: It automatically adds your project's root directory to Python's sys.path, allowing relative imports between your files to work flawlessly.
• Visualization Injection: It patches libraries like Matplotlib and Plotly, intercepting their graphical output and converting it into a payload that can be rendered safely in your browser.
• Log Protection: It overrides sys.stdout to prevent runaway scripts from filling your hard drive, enforcing a rolling 5MB shield on output logs.

Execution Lifecycles

How your script physically runs on the server depends entirely on your account tier. We employ two distinct operational lifecycles.

Free Tier: The Ephemeral Lifecycle

For Guest and Free users, execution follows a stateless "Batch Process" philosophy.

• The Spawning: Every time you hit Run, the backend creates a brand new, isolated Linux container specifically for that execution.
• The Clean Slate: Because the container is new, it has fresh RAM. Variables or memory state from a previous run cannot leak into the current run.
• The 60-Second Wall: To prevent infinite loops from hoarding server resources indefinitely, the Free tier imposes a hard 60-second timeout. If your script exceeds this limit, the backend issues a SIGKILL signal, forcibly terminating the container.

Pro Tier: The Fire-and-Forget Daemons

For Pro users, execution takes place inside your permanent, 24/7 Cloud Workstation using a Detached I/O Bridge.

• The Injection: When you hit Run, the system does not spawn a new container. Instead, it uses a docker exec command to inject the Python process directly into your already-running 24/7 Workstation.
• No Timeouts: Because the workstation belongs entirely to you, there are no execution timers. If your script takes 6 hours to process a massive dataset, it will run for 6 hours uninterrupted.
• Shared Environment: Your script has access to any environment variables or background services you may have started in the Pro Terminal.

Handling Input()

Python's built-in input() function asks the user for text. Because Pro scripts run completely detached from the browser in the background, they cannot use a standard terminal interface.

Instead, the platform uses a File Queue. When your script asks for input, the UI generates a text box. When you type your answer and hit Enter, your running script reads your answer, and continues execution seamlessly.

Stopping Execution

Once a script is running, the Run button turns into a red Stop button.

• Free Tier: Clicking Stop instantly destroys the ephemeral container, halting the process immediately.
• Pro Tier: Clicking Stop sends a termination signal to the specific Python process running inside your workstation, killing the script while leaving the underlying workstation perfectly intact.