CertGrid CertGrid
Installation·Certified Entry-Level Python Programmer

Python Practice Environment

Every other path on this site needs a cluster or a pair of managed hosts. This one needs a shell with Python 3 in it. That is worth saying explicitly rather than leaving a reader to discover it, because it changes how you should study: you can follow every guide here on the laptop you are reading it on, and the only thing worth checking first is which interpreter you have.

Start Here Guide 2 of 26 Beginner

Written against the versions above. The captures in this path came from **Python 3.14.4** on Ubuntu 26.04. Any Python 3.8 or newer will run almost everything here, but error messages improved a great deal between 3.10 and 3.14 and several of them appear verbatim in these guides - see {{guide:python-314-versus-the-syllabus}}.

One machine, and any shell with Python 3 will do - these exams test the language, not a distribution.
Server NameIP AddressOSRolesCPURAMHDD
RUNNER01192.168.0.27Ubuntu 26.04 LTSPython 3.14.4 - the only machine this path needs2 Core4 GB50 GB

Before you start

  1. The interpreter this guide assumes

    Every command in this guide was run on RUNNER01 with the interpreter below. There is nothing to install and no service to configure - both exams test the language itself, so any shell with Python 3 will do, including your own laptop.

    One thing is worth confirming rather than assuming: the exact interpreter version. PCEP-30-02 and PCAP-31-03 were written well before Python 3.14, and a handful of behaviours have changed since - error message wording most visibly. Where a capture on this page shows something that would have looked different on an older interpreter, the guide says which release changed it.

    Scratch files live in ~/py, and every guide that writes one removes it. Nothing in this path needs sudo, and nothing it does can affect the rest of the machine.

    bash Example session 
    python3 --versionPython 3.14.4python3 -c "import sys; print(sys.executable)"/usr/bin/python3python3 -c "import sys; print(sys.version)"3.14.4 (main, Jun 18 2026, 14:25:02) [GCC 15.2.0]mkdir -p ~/py && ls -d ~/py/home/sysadmin/py

    Expected resultPython 3.14.4, and a directory to write scratch files in.

    Success conditionYour interpreter matches the one every output on this page came from.

  2. Why there is only one machine

    The lab table above has one row, and that is not a simplification.

    PCEP and PCAP examine the language. Between them the two blueprints cover literals, operators, control flow, four collection types, functions, scope, exceptions, modules, classes, comprehensions, lambdas, closures and file I/O. Not one of those needs a service running, a port open, a second host to talk to, or root. Everything in this path is a file in a directory and an interpreter reading it.

    That has three consequences worth acting on.

    You do not need this machine. Any Python 3 gives the same answers. The server table exists so you can see which interpreter produced the output on the page, not because the box is special.

    Nothing here needs sudo. No guide in this path installs a package, edits a file outside your home directory, or starts anything. If a step ever seems to want root, it is a mistake - report it.

    Scratch files are disposable. Every guide that writes one names it, uses it and removes it. ~/py is the only directory this path touches, and it is empty again at the end of every page.

    bash Example session 
    mkdir -p ~/py && ls -d ~/py/home/sysadmin/py

    Expected resultA directory under your home. That is the entire lab.

    Success conditionYou have somewhere to put scratch files, and nothing else to prepare.

  3. The one thing worth checking: which interpreter you have

    This is the check that actually matters, because two guides in this path show output that a different interpreter would print differently.

    sys.version gives the full string, including the build date and the compiler - useful when comparing against a colleague's box. sys.version_info gives the same thing as a tuple you can compare in code, and it is the form worth remembering: PCAP objective 1.4 asks about platform.python_version_tuple(), which returns the same three numbers as strings rather than integers.

    bash Example session 
    python3 -c "import sys; print(sys.version)"3.14.4 (main, Jun 18 2026, 14:25:02) [GCC 15.2.0]python3 -c "import sys; print(sys.version_info)"sys.version_info(major=3, minor=14, micro=4, releaselevel='final', serial=0)

    Expected resultA version string, then a named tuple - major=3, minor=14, micro=4 here.

    Success conditionYou can state your interpreter version exactly, in both forms.

  4. How code is run in these guides

    Every code sample in this path follows the same two-command shape, so you can copy either half and know what it does. The quoted <<'PY' matters: it stops the shell touching $, backticks or backslashes inside the code, which matters the moment a sample contains a string like "\n".

    bash Example session 
    cat > ~/py/hello.py <<'PY'name = "PCEP"print("hello,", name)PYpython3 ~/py/hello.pyhello, PCEP

    Expected resulthello, PCEP.

    Success conditionYou can run any sample in this path.

  5. Why a file rather than the prompt or -c

    Because of what a traceback says.

    Run from a file, a traceback names the file and the line for every frame - here the call site on line 5 and the division on line 2. That is most of what a traceback is for, and several guides in this path are built on reading one.

    The same failure through python3 -c reports File "" and a line number that refers to nothing you can open. Typed at the interactive >>> prompt it reports File "", which is no better.

    bash Example session 
    cat > ~/py/boom.py <<'PY'def middle():    return 1 / 0  print(middle())PYpython3 ~/py/boom.pyTraceback (most recent call last):  File "/home/sysadmin/py/boom.py", line 5, in <module>    print(middle())          ~~~~~~^^  File "/home/sysadmin/py/boom.py", line 2, in middle    return 1 / 0           ~~^~~ZeroDivisionError: division by zero[exit 1]python3 -c 'print(1 / 0)'Traceback (most recent call last):  File "<string>", line 1, in <module>    print(1 / 0)          ~~^~~ZeroDivisionError: division by zero[exit 1]

    Expected resultTwo frames with a real path and real line numbers, then the same exception reported against <string>.

    Success conditionYou can see why the file form is used for anything longer than one line.

  6. If you are on Windows without WSL

    Every code sample in this path is pure Python and runs unchanged under py or python on Windows. What will not run is the cat > file <<'PY' wrapper around it, which is a POSIX shell idiom.

    Paste the code into a file with any editor and run python name.py instead. The output is identical, with one cosmetic exception: paths in tracebacks appear as File "C:\\Users\\you\\py\\boom.py" rather than /home/sysadmin/py/boom.py.

    There is also nothing to install beyond Python itself. No virtual environment is needed anywhere in this path, because no guide installs a package - venv and pip are good practice in real work and are examined by neither exam. The one place the module system *is* examined is writing your own module and package, and that is plain files on sys.path with no tooling at all - guide 8.

    bash Example session 
    python3 -c "import sys; print(sys.executable)"/usr/bin/python3

    Expected resultThe interpreter path. On Windows this is a C:\...\python.exe instead.

    Success conditionYou know what differs on Windows, and that it is only the shell around the code.

Troubleshooting

Official sources

← All PCEP guides