Python for coding rounds: input, output, limits

A coding round runs your program on an online judgeonline judge: A service that runs a submitted program on hidden tests: it gives each test's input on standard input, compares everything the program prints with the expected answer, and gives a verdict for every test, under a time limit and a memory limit.: each test’s input arrives on standard inputstandard streams: The three text channels every program starts with: standard input to read from, standard output for its results and standard error for messages. In Python they are sys.stdin, sys.stdout and sys.stderr. More in “Input and output: print(), input() and stdin”, everything the program prints is compared with the expected answer, and the run must finish within a time limit, often one or two seconds, and a memory limit. Python is fast enough for these limits when a solution keeps four habits: read the whole input in one call with sys.stdin.buffer.read().split(), collect the answers and write them in one call, replace recursion with a loop when the depth grows with the input, and remember that an int never overflows but refuses to become more than 4,300 decimal digits of text.

Each habit is measured or shown below on CPython 3.14.8, with the time it saves or the error it prevents. You will step through one test of a judge and the template’s walk over its input, and leave with a template to start every solution from.

A judge compares everything you print

Each test runs your program the same way, from its input to a verdict:

Nobody types anything and nobody reads a prompt. Two consequences catch people out in their first round:

• A prompt is part of your answer. input("Enter n: ") writes Enter n: to standard output, so the judge sees it in front of your first answer and reports a wrong answer. Call input() without a prompt, or better, read the input the way the next section does.
• The slowest test decides. A solution is accepted only if every test passes, and the last tests are usually the largest the problem allows. Read the limits in the statement, such as “n ≤ 2 × 10⁵”, as the size your program must handle, not the size of the examples.

Each judge states how strictly it compares, and many ignore spaces at the ends of lines and the final line break. An extra word or a stray debugging line is a wrong answer everywhere, so debugging output belongs on standard error (print(..., file=sys.stderr)), which judges do not compare with the answer. Follow one test of a program that still asks for its input with a prompt, and watch where each line it prints ends up:

Every number was right and the verdict was still wrong, because the judge compares the text on standard output and nothing else. Removing the prompt fixed the test without touching the logic.

One template: read once, solve, write once

The template keeps reading and writing in one place and the thinking in another. The example problem: each class lists its marks, and the answer is how many marks are above the class average.

import sys


def solve(tokens):
    """Answers every test case: how many marks are above the class average."""
    it = iter(tokens)
    out = []
    for _ in range(int(next(it))):
        n = int(next(it))
        marks = [int(next(it)) for _ in range(n)]
        total = sum(marks)
        # m > total / n, compared without floats: m * n > total
        out.append(str(sum(1 for m in marks if m * n > total)))
    return out


def main():
    tokens = sys.stdin.buffer.read().split()
    sys.stdout.write("\n".join(solve(tokens)) + "\n")


if __name__ == "__main__":
    main()

3
5
40 75 90 60 35
4
50 50 50 50
3
10 20
31

2
0
1

• main() reads every byte of standard input in one call and splits it on any whitespace, so it does not matter how the numbers are spread over lines. The third class has its last mark on a line of its own, and nothing breaks.
• solve() walks through the tokens with an iterator: next(it) takes the next token wherever it is. It returns the answers as a list of strings instead of printing them, which makes it easy to test: a test imports solve and compares its result, as this lesson’s exercise does.
• main() writes all the answers with one sys.stdout.write(). The if __name__ == "__main__": guard, the main guardmain guard: The block under if __name__ == "__main__": in a file. It runs when the file is started as the program and is skipped when the file is imported, because __name__ then holds the module's own name. More in “Modules, imports and __name__”, runs it only when the file is run as a program, not when a test imports it. Keeping the work inside functions also makes it faster, because Python reaches a function’s local variables more quickly than names at module level; the next lesson measures the difference.
• The comparison m * n > total asks “is m above the average?” without dividing. Whole numbers stay exact at any size, while a float average such as 61 ÷ 3 is rounded to about 16 significant digits, which can flip a comparison once the numbers are huge.

Step through the same walk over the same input, written out at the top level with a loop for each mark, so that every token the iterator hands over is a step of its own. The flag under tokens is the token the next next(it) hands over:

data = (b"3\n5\n40 75 90 60 35\n"
        b"4\n50 50 50 50\n"
        b"3\n10 20\n31\n")
tokens = data.split()
it = iter(tokens)
out = []
for _ in range(int(next(it))):
    n = int(next(it))
    marks = [0] * n
    for i in range(n):
        marks[i] = int(next(it))
    total = sum(marks)
    above = sum(1 for m in marks if m * n > total)
    out.append(str(above))
print("\n".join(out))

2
0
1

The split turned the eight lines of input into one flat list of 16 tokens, and next(it) took them in order: the 5 said how many marks followed, and 31, alone on its line, arrived like any other token.

Reading sys.stdin.buffer gives bytes, not text. Numbers do not care, because int() and float() accept bytes, but comparing a token with a string does:

# What sys.stdin.buffer.read() returns for this input: bytes, not str
raw = b"YES 42\n-7 3.5\nRavi Kumar\n"

tokens = raw.split()
print(tokens)
print(int(tokens[1]) + int(tokens[2]), float(tokens[3]))  # int() and float() accept bytes

print(tokens[0] == "YES")             # bytes never equal str: False
print(tokens[0] == b"YES")            # compare with a bytes literal
print(tokens[0].decode() == "YES")    # or decode the token first

lines = raw.splitlines()              # for a line with spaces in it
print(lines[2].decode())

[b'YES', b'42', b'-7', b'3.5', b'Ravi', b'Kumar']
35 3.5
False
True
True
Ravi Kumar

A line that contains spaces, such as a name, is split into several tokens; read such inputs line by line with splitlines() instead.

Reading everything in one call is many times faster

How much does the way of reading matter? This program writes a file of 1,000,000 numbers, one per line, and runs four small programs on it, each in a fresh Python with the file on its standard input, exactly as a judge would. Each one adds the numbers up and reports how long its reading took:

"""Reads 1,000,000 numbers from standard input four ways, each in a fresh Python, as a judge would run it.

Each way runs three times and the fastest run counts: slower runs are mostly other programs getting in the way."""
import os
import subprocess
import sys
import tempfile
import tracemalloc

N = 1_000_000
READERS = {
    "input() per line": "total = sum(int(input()) for _ in range(n))",
    "sys.stdin.readline() per line": "readline = sys.stdin.readline\ntotal = sum(int(readline()) for _ in range(n))",
    "sys.stdin.read().split()": "total = sum(map(int, sys.stdin.read().split()))",
    "sys.stdin.buffer.read().split()": "total = sum(map(int, sys.stdin.buffer.read().split()))",
}
# The child times only its reading and adding, then prints the sum and the milliseconds.
CHILD = """import sys, time
n = {n}
start = time.perf_counter()
{body}
print(total, round((time.perf_counter() - start) * 1000))
"""

with tempfile.TemporaryDirectory() as folder:
    path = os.path.join(folder, "input.txt")
    with open(path, "w") as f:
        f.write("\n".join(str(i * 7 % 1_000_003) for i in range(N)) + "\n")
    for name, body in READERS.items():
        runs = []
        for _ in range(3):
            with open(path, "rb") as stdin:
                run = subprocess.run(
                    [sys.executable, "-c", CHILD.format(n=N, body=body)],
                    stdin=stdin, capture_output=True, text=True, check=True,
                )
            runs.append(tuple(map(int, run.stdout.split())))
        total, ms = min(runs, key=lambda r: r[1])
        print(f"{name:32} sum {total:,} in {ms:>5,} ms")
    with open(path, "rb") as f:
        data = f.read()
    tracemalloc.start()
    tokens = data.split()
    print(f"memory for the {len(tokens):,} tokens of one split(): {tracemalloc.get_traced_memory()[0] / 1e6:.1f} MB")

input() per line                 sum 499,999,500,036 in 2,053 ms
sys.stdin.readline() per line    sum 499,999,500,036 in   135 ms
sys.stdin.read().split()         sum 499,999,500,036 in    86 ms
sys.stdin.buffer.read().split()  sum 499,999,500,036 in    76 ms
memory for the 1,000,000 tokens of one split(): 47.4 MB

All four agree on the sum; they differ in time by a factor of about twenty or more. input() is built for a person at a keyboard: every call does work that a judge’s input does not need, from handling a possible prompt to raising two auditing events, before it reads one line, and a million calls of that extra work cost seconds. sys.stdin.readline() reads one line per call without that overhead, which is fine when the input really is line by line. Reading everything with read().split() is the fastest and the simplest, and sys.stdin.buffer skips decoding the bytes into text, which saves a little more.

The price is memory, shown on the last line: every token is a small bytes object, about 50 bytes each with its place in the list, and all of them exist at once. A few million numbers fit easily in a memory limit of 256 MB; for an input far larger than the memory limit, read it line by line instead.

Write the output once; flush only for an interactive judge

Output has the same problem in reverse: one print() per answer is a function call per line. This program writes 200,000 lines three ways, each into a file, which is where a judge’s output goes:

"""Writes 200,000 answer lines three ways, each in a fresh Python with its output going to a file, as on a judge.

Each way runs three times and the fastest run counts."""
import os
import subprocess
import sys
import tempfile

N = 200_000
WRITERS = {
    "print() per line": "for i in range(n):\n    print(i)",
    "print(..., flush=True) per line": "for i in range(n):\n    print(i, flush=True)",
    "one join, one write": 'sys.stdout.write("\\n".join(map(str, range(n))) + "\\n")',
}
# The child writes its answers to standard output and its time, in milliseconds, to standard error.
CHILD = """import sys, time
n = {n}
start = time.perf_counter()
{body}
sys.stdout.flush()
print(round((time.perf_counter() - start) * 1000), file=sys.stderr)
"""

with tempfile.TemporaryDirectory() as folder:
    path = os.path.join(folder, "output.txt")
    for name, body in WRITERS.items():
        times = []
        for _ in range(3):
            with open(path, "w") as out:
                run = subprocess.run(
                    [sys.executable, "-c", CHILD.format(n=N, body=body)],
                    stdout=out, stderr=subprocess.PIPE, text=True, check=True,
                )
            times.append(int(run.stderr))
        print(f"{name:32} {os.path.getsize(path):,} bytes in {min(times):>5,} ms")

print() per line                 1,288,890 bytes in    59 ms
print(..., flush=True) per line  1,288,890 bytes in 1,181 ms
one join, one write              1,288,890 bytes in    19 ms

All three files are the same size. Joining the lines and writing once is the fastest. Plain print() per line is slower but still reasonable, because when standard output is a file or a pipe, Python collects it in an output bufferoutput buffer: Memory where written text waits before it is sent on: a line at a time when standard output is a terminal, in larger blocks for a file or a pipe. print(..., flush=True) sends it at once. More in “Input and output: print(), input() and stdin” and writes it in large blocks. flush=True gives up that saving: every line becomes its own write to the operating system, and the same output takes many times as long. Step through what the buffer does with each line, first in an ordinary problem and then in an interactive one:

Recursion stops near 1,000 frames; a list of your own does not

Every unfinished call keeps a frameframe: The record of one function call that has not finished: its local variables and the place to carry on when the call it is waiting for returns. More in “Recursion, the call stack and its limits”, and CPython stops at a recursion limitrecursion limit: The most frames CPython allows on its call stack at once, 1,000 by default, counting the frames below your first call. Going past it raises RecursionError. More in “Recursion, the call stack and its limits” of 1,000 frames by default. That is plenty for most recursion, but not for a depth-first search over a graph shaped like a long path, because the search goes one frame deeper for every node:

import sys

N = 100_000
# A path 0 - 1 - 2 - ... - 99,999: the deepest graph a depth-first search can meet
graph = [[] for _ in range(N)]
for v in range(N - 1):
    graph[v].append(v + 1)
    graph[v + 1].append(v)


def dfs_recursive(v, seen):
    seen.add(v)
    for w in graph[v]:
        if w not in seen:
            dfs_recursive(w, seen)


def dfs_iterative(start):
    seen = {start}
    stack = [start]  # the nodes still to explore, in a list of our own
    while stack:
        v = stack.pop()
        for w in graph[v]:
            if w not in seen:
                seen.add(w)
                stack.append(w)
    return seen


print("recursion limit:", sys.getrecursionlimit())
seen = set()
try:
    dfs_recursive(0, seen)
    print(f"recursive DFS visited {len(seen):,} nodes")
except RecursionError as error:
    print(f"recursive DFS stopped with {type(error).__name__} after {len(seen):,} nodes")
print(f"iterative DFS visited {len(dfs_iterative(0)):,} nodes")

recursion limit: 1000
recursive DFS stopped with RecursionError after 999 nodes
iterative DFS visited 100,000 nodes

recursion limit: 1000
recursive DFS stopped with RecursionError after 994 nodes
iterative DFS visited 100,000 nodes

Step through what the recursive search does to the call stack, and what the iterative search keeps instead:

The iterative version keeps the nodes still to explore in a list of its own, an explicit stackexplicit stack: A list that a loop uses to keep the work still to do, in place of recursive calls: append() pushes an item and pop() takes the last one. Only memory limits its size. More in “Recursion, the call stack and its limits”, and takes the last one each time, as the call stack does, but without its limit. A list holds millions of items, so the depth no longer matters. The order in which neighbours are visited can differ from the recursive version, which rarely matters for a search; when it does, push the neighbours in reverse order and mark a node as seen when it is taken from the list, not when it is put on it.

Raising the limit is the other common answer, and it works only for some recursion. Since Python 3.11, most calls from Python code to a Python function use no C stack at all, so plain recursion can go much deeper once the limit is raised. A call that passes through C code, such as a function wrapped by functools.cache, still uses the C stack, which has a fixed size:

import functools
import sys
import threading

sys.setrecursionlimit(1_000_000)


def depth(n):
    return 0 if n == 0 else 1 + depth(n - 1)


@functools.cache
def cached_depth(n):
    return 0 if n == 0 else 1 + cached_depth(n - 1)


def attempt(f, n):
    try:
        return f"{f(n):,} levels"
    except RecursionError as error:
        return "RecursionError: " + str(error).split(" (")[0]


print("plain function, 100,000 deep: ", attempt(depth, 100_000))
print("cached function, 10,000 deep: ", attempt(cached_depth, 10_000))

# The workaround some judge solutions use: a thread with a much larger stack
threading.stack_size(512 * 1024 * 1024)
cached_depth.cache_clear()
result = []
worker = threading.Thread(target=lambda: result.append(attempt(cached_depth, 100_000)))
worker.start()
worker.join()
print("cached function, 100,000 deep, 512 MiB thread stack:", result[0])

plain function, 100,000 deep:  100,000 levels
cached function, 10,000 deep:  RecursionError: Stack overflow
cached function, 100,000 deep, 512 MiB thread stack: 100,000 levels

With the limit at a million, the plain function went 100,000 levels deep, but the cached one failed on a recursion 10,000 levels deep: CPython 3.14 protects its C stack and raised RecursionError with the message “Stack overflow” instead of crashing. A thread created after threading.stack_size() gets a larger stack, and with 512 MiB the cached function reached 100,000 levels. That workaround depends on the platform and on how much memory the judge allows, so treat it as a last resort; the documentation of sys.setrecursionlimit() adds that a very high limit can make Python crash. The explicit stack works everywhere.

Python ints never overflow, but their decimal text stops at 4,300 digits

Python’s integers grow as large as memory allows, so sums and products never overflow as they can in C++ or Java. Two limits remain:

import math
import sys

E = 20_000  # the exponent: try 14_284, then 14_285
x = 2 ** E  # Python ints never overflow
print("bits:", x.bit_length())
print("decimal digits:", math.floor(math.log10(x)) + 1)

try:
    print(str(x))
except ValueError as error:
    print("ValueError:", error)

print("hex digits:", len(hex(x)) - 2)  # power-of-two bases have no limit

sys.set_int_max_str_digits(0)  # 0 removes the limit, for this program only
print("first digits:", str(x)[:12])

MOD = 10**9 + 7  # judges often ask for the answer modulo a prime like this
print(f"2 ** {E} % MOD =", x % MOD, "=", pow(2, E, MOD))

bits: 20001
decimal digits: 6021
ValueError: Exceeds the limit (4300 digits) for integer string conversion; use sys.set_int_max_str_digits() to increase the limit
hex digits: 5001
first digits: 398027684033
2 ** 20000 % MOD = 614428880 = 614428880

• Text conversion. Turning an int into decimal text, or decimal text into an int, is not a linear-time job for huge numbers, so CPython refuses numbers of more than 4,300 decimal digits by default, a protection against inputs that would keep a server busy. hex(), bin() and oct() have no limit, and sys.set_int_max_str_digits(0) removes it for one program when a problem really asks you to print a huge number.
• Speed. Arithmetic on a number with thousands of digits takes far longer than on a small one. When a problem asks for the answer “modulo 10⁹ + 7”, it wants you to reduce after every step so that the numbers stay small: (a * b) % MOD in a loop, or pow(a, b, MOD), which computes a modular power without ever building the huge number. The example checks that both ways give the same remainder.

Check which Python the judge runs before you use a new feature

Judges list the language versions they offer, and code that uses a feature newer than the judge’s Python fails there with a runtime error, even though it works at home. The first submission to a new judge can print the version to standard error, and features can be checked at run time:

import heapq
import itertools
import math
import sys

print("implementation:", sys.implementation.name)
print("version:", "%d.%d" % sys.version_info[:2])
print("math.lcm, Python 3.9+:", hasattr(math, "lcm"))
print("itertools.batched, Python 3.12+:", hasattr(itertools, "batched"))
print("heapq.heappush_max, Python 3.14+:", hasattr(heapq, "heappush_max"))

implementation: cpython
version: 3.14
math.lcm, Python 3.9+: True
itertools.batched, Python 3.12+: True
heapq.heappush_max, Python 3.14+: True

math.lcm() needs Python 3.9, itertools.batched() 3.12 and heapq.heappush_max() 3.14. Walk through the versions that added the features solutions use most:

Some judges also offer PyPyPyPy: A separate implementation of the Python language with a just-in-time compiler, which turns code that runs often into machine code while the program runs. It implements an older version of the language than the newest CPython., a separate implementation of Python with a just-in-time compiler. Its project reports that, on average, PyPy 3.12 runs about four times as fast as CPython 3.11, and it supports the language of Python 3.12 and 3.11, so features added in 3.13 or 3.14 are missing there. Submit to PyPy when a correct solution is close to the time limit and uses nothing newer than its version.

Practise: three judge-style problems at full size

Practise with problems that are original or openly licensed, such as the ones in this track and the Data Structures & Algorithms (DSA) and coding-patterns tracks of MySmartCoPilot. The questions of companies’ online assessments belong to those companies, and MySmartCoPilot never republishes them; a question that “was asked” somewhere teaches nothing that an original problem of the same pattern does not. Before you submit any solution, run six checks:

1. Run the largest input. Generate one at the limits of the statement with a few lines of Python, and time the whole program on it, reading and writing included.
2. Clean standard output. No prompts, no debugging lines: only the answers, in the order asked.
3. Match the format exactly. One answer per line unless told otherwise, the exact spelling of words such as YES, and the number of decimal places the statement asks for.
4. Remove deep recursion. Any recursion whose depth grows with the input becomes a loop with a stack.
5. Reduce as you go. When the answer is asked modulo a prime, take the remainder after every step.
6. Check the version. Use only what the judge’s Python, or PyPy, provides.

The exercise has three problems at the sizes a judge would use. Each function receives the whole input as bytes and returns the whole output, and the sample tests include inputs at the limits:

from collections import Counter, deque


def range_sums(data):
    """The sum of a[l..r] for every pair l r, one per line."""
    return ""


def frequency_of_frequencies(data):
    """Lines "c k": k distinct words occur exactly c times, by increasing c."""
    return ""


def grid_steps(data):
    """The least number of moves from S to E, or -1."""
    return ""

from judge import frequency_of_frequencies, grid_steps, range_sums


def lines(text):
    """The output's lines, without spaces at their ends or blank lines at the end."""
    return [line.rstrip() for line in str(text).strip().splitlines()]


def letters(i):
    """A different word of small letters for every number i."""
    word = ""
    while True:
        i, r = divmod(i, 26)
        word += "abcdefghijklmnopqrstuvwxyz"[r]
        if i == 0:
            return word


def test_range_sums_sample():
    """answers each pair with the sum of its range"""
    data = b"5 4\n3 -1 4 1 5\n1 5\n2 3\n4 4\n1 1\n"
    assert lines(range_sums(data)) == ["12", "3", "1", "3"]


def test_range_sums_at_the_limits():
    """answers 200,000 pairs over 200,000 numbers in time"""
    n = 200_000
    numbers = " ".join(str(i if i % 2 else -i) for i in range(1, n + 1))  # 1 -2 3 -4 ...
    pairs = [(i, n - i + 1) for i in range(1, n // 2 + 1)] + [(i, i) for i in range(1, n // 2 + 1)]

    def first(k):  # 1 - 2 + 3 - 4 ... up to the k-th number
        return (k + 1) // 2 if k % 2 else -(k // 2)

    text = f"{n} {len(pairs)}\n{numbers}\n" + "\n".join(f"{l} {r}" for l, r in pairs) + "\n"
    out = lines(range_sums(text.encode()))
    assert len(out) == len(pairs)
    assert out[:3] == ["-100000", "99999", "-99998"]
    assert out == [str(first(r) - first(l - 1)) for l, r in pairs]


def test_frequency_sample():
    """counts how many words share each count"""
    data = b"9\ntea coffee tea\nmilk tea water\ncoffee milk juice\n"
    assert lines(frequency_of_frequencies(data)) == ["1 2", "2 2", "3 1"]


def test_frequency_at_the_limits():
    """handles 200,000 words in time"""
    words = []
    for i in range(1, 501):  # one word that occurs once, one twice ... one 500 times
        words += ["w" + letters(i)] * i
    words += ["z" + letters(i) for i in range(74_750)]  # and 74,750 words that occur once
    assert len(words) == 200_000
    out = lines(frequency_of_frequencies(f"{len(words)}\n{' '.join(words)}\n".encode()))
    assert out == ["1 74751"] + [f"{c} 1" for c in range(2, 501)]


def test_grid_sample():
    """finds the shortest way round the walls"""
    data = b"4 5\nS..#.\n.#.#.\n.#...\n...#E\n"
    assert lines(grid_steps(data)) == ["7"]


def test_grid_all_directions():
    """moves up and left as well as down and right"""
    assert lines(grid_steps(b"3 5\nS#.#E\n.#.#.\n.....\n")) == ["8"]
    assert lines(grid_steps(b"3 5\nE#.#S\n.#.#.\n.....\n")) == ["8"]


def test_grid_unreachable():
    """prints -1 when the exit is walled off"""
    data = b"3 3\nS#.\n##.\n..E\n"
    assert lines(grid_steps(data)) == ["-1"]


def test_grid_at_the_limits():
    """searches a 300 x 300 grid in time"""
    rows = ["." * 300 for _ in range(300)]
    rows[0] = "S" + rows[0][1:]
    rows[-1] = rows[-1][:-1] + "E"
    assert lines(grid_steps(("300 300\n" + "\n".join(rows) + "\n").encode())) == ["598"]

Last, test the whole lesson on yourself. The practice below opens with whichever idea you have answered least well, and every answer is explained straight away:

Interview questions

Fresher · Why do coding-round solutions read sys.stdin.buffer instead of calling input() in a loop?

Because the input of a judge’s test arrives all at once, and reading it in one call is both faster and simpler. input() is designed for a person typing: every call can write a prompt, raises auditing events and returns one line as text, so a million calls add up to seconds, while one sys.stdin.buffer.read().split() reads the same million numbers in about a tenth of a second. Splitting on any whitespace also stops caring how the numbers are spread over lines. buffer skips decoding bytes to text; the tokens are bytes, which int() accepts, but compare them with bytes literals or decode them first. The cost is memory, since every token is held at once, which is fine for typical limits. For line-structured input, sys.stdin.readline is a good middle way.

Key takeaways

• A judge feeds each test on standard input and compares everything you print, so prompts and debugging lines stay off standard output, and one failing test fails the whole submission.
• Read the whole input with sys.stdin.buffer.read().split() and walk the tokens with next(it): the line breaks stop mattering, the reading is many times faster, and the tokens are bytes.
• Collect the answers and write them with one sys.stdout.write("\n".join(lines)); flush line by line only in interactive problems, where the judge waits for each query.
• Recursion stops near 1,000 frames by default, and raising the limit does not help recursion through C code; a loop with a list of your own works on any judge.
• int never overflows, but decimal text conversion stops at 4,300 digits by default, and modular answers want % MOD after every step or pow(a, b, MOD).
• A feature added in a recent Python fails on a judge with an older one, so check the judge’s version, or PyPy’s, before you rely on it.