CertGrid CertGrid
Troubleshooting·Certified Entry-Level Python Programmer

Python 3.14 and Exam Version Differences

PCEP-30-02 and PCAP-31-03 were written against a much older Python 3, and studying on a current interpreter quietly introduces disagreements. Most are harmless - better error messages than the exam will show you. One is not: Python 3.14 made legal a syntax that was an error for the whole of Python 3's history, and that older PCAP material teaches you to spot as broken. Every behaviour here was run on the machine and the release that changed it is named.

Start Here Guide 3 of 26 Beginner

Written against the versions above. Captured on **Python 3.14.4**. Each item names the release that introduced the behaviour, so you can predict what your own interpreter will do. Where the exam's expected answer differs from 3.14's, that is stated outright.

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 one that matters: except without parentheses

    For the entire history of Python 3, catching two exception types required a tuple in parentheses. except ValueError, TypeError: was a SyntaxError - it was Python 2 syntax, where the comma introduced the name to bind the exception object to, and removing it was one of the more visible Python 3 changes. Older PCAP material teaches you to recognise that line as broken, and "which of these is a syntax error?" is a question shape both exams use.

    Python 3.14 made it legal again, with the Python 3 meaning: a tuple of types, parentheses optional. PEP 758.

    bash Example session 
    cat > ~/py/except_tuple.py <<'PY'try:    int("x")except ValueError, TypeError:    print("caught - and the parentheses are gone")PYpython3 ~/py/except_tuple.pycaught - and the parentheses are gone

    Expected resultIt runs. No SyntaxError, no warning, and the except catches normally.

    Success conditionYou have seen the one 3.14 change that can cost you a mark.

  2. Error messages now tell you the answer

    The exams ask you to identify what a broken program raises. On a current interpreter the traceback often names the fix as well, which is a much gentler experience than the one you will get in the exam window.

    NameError suggestions arrived in Python 3.10. The interpreter compares the unknown name against the names in scope and offers the closest.

    bash Example session 
    cat > ~/py/typo.py <<'PY'length = 5print(lenght)PYpython3 ~/py/typo.pyTraceback (most recent call last):  File "/home/sysadmin/py/typo.py", line 2, in <module>    print(lenght)          ^^^^^^NameError: name 'lenght' is not defined. Did you mean: 'length'?[exit 1]

    Expected resultNameError: name 'lenght' is not defined. Did you mean: 'length'?

    Success conditionYou know the suggestion is a 3.10+ courtesy, not part of the exception name.

  3. The same courtesy for attributes and modules

    AttributeError suggestions arrived in Python 3.12, and they cover module attributes as well as object attributes. PCAP section 1 is the math, random and platform modules, so this is the message you will see most while practising - and the one that will most obviously be missing when it counts.

    bash Example session 
    cat > ~/py/attr.py <<'PY'import mathprint(math.sqr(4))PYpython3 ~/py/attr.pyTraceback (most recent call last):  File "/home/sysadmin/py/attr.py", line 2, in <module>    print(math.sqr(4))          ^^^^^^^^AttributeError: module 'math' has no attribute 'sqr'. Did you mean: 'sqrt'?[exit 1]

    Expected resultAttributeError: module 'math' has no attribute 'sqr'. Did you mean: 'sqrt'?

    Success conditionYou can name the exception type without leaning on the suggestion.

  4. return in a finally block is now a warning

    finally runs whatever happens, and a return inside it discards any value or exception the try was carrying. That has always been true and is examinable under PCAP objective 2.1 - a question that shows this and asks what the function returns expects the answer 2, not 1.

    Python 3.14 now warns about it. PEP 765.

    bash Example session 
    cat > ~/py/finally_return.py <<'PY'def f():    try:        return 1    finally:        return 2 print(f())PYpython3 ~/py/finally_return.py/home/sysadmin/py/finally_return.py:5: SyntaxWarning: 'return' in a 'finally' block  return 22

    Expected resultA SyntaxWarning naming line 5, and then the answer: 2.

    Success conditionThe behaviour is unchanged - only the warning is new.

  5. Very large integers no longer print

    PCEP objective 1.3 covers integers and numeral systems, and the usual demonstration of Python's unbounded integers is to compute something absurd and print it. On any Python 3.11 or newer that fails, because converting an int to a str is capped at 4300 digits by default - a denial-of-service fix, since the conversion is quadratic in the number of digits.

    bash Example session 
    python3 -c 'print(len(str(2 ** 20000)))'Traceback (most recent call last):  File "<string>", line 1, in <module>    print(len(str(2 ** 20000)))              ~~~^^^^^^^^^^^^ValueError: Exceeds the limit (4300 digits) for integer string conversion; use sys.set_int_max_str_digits() to increase the limit[exit 1]python3 -c 'print(int("1" * 5000))'Traceback (most recent call last):  File "<string>", line 1, in <module>    print(int("1" * 5000))          ~~~^^^^^^^^^^^^ValueError: Exceeds the limit (4300 digits) for integer string conversion: value has 5000 digits; use sys.set_int_max_str_digits() to increase the limit[exit 1]

    Expected resultValueError: Exceeds the limit (4300 digits) for integer string conversion - in both directions.

    Success conditionYou know the arithmetic is unbounded and only the text conversion is capped.

  6. Invalid escape sequences warn now and will break later

    PCEP objective 3.4 and PCAP section 3 both cover string literals and escapes. \n and \t are real escapes; \d is not, and Python has historically passed unknown escapes through unchanged. Since Python 3.12 that is a SyntaxWarning, and the message says plainly that it will stop working.

    bash Example session 
    python3 -c 'print("\d")'<string>:1: SyntaxWarning: "\d" is an invalid escape sequence. Such sequences will not work in the future. Did you mean "\\d"? A raw string is also an option.\dpython3 -c 'print(r"\d")'\d

    Expected resultA warning and then \d - followed by the raw-string form, which prints the same thing silently.

    Success conditionYou can explain why the second command is the correct way to write the first.

  7. What has not changed

    It is as useful to know what is stable, because a great deal of advice online claims otherwise. Every row below is printed by the script, not asserted here:

    | Claim you will meet | The line that answers it | |---|---| | "Integer division changed" | floored division | | "print needs no parentheses in newer Python" | print is a | | "String methods were renamed or removed" | public str methods, str.decode exists | | "platform.linux_distribution() is back" | linux_distribution | | "Dictionaries are unordered" | dict keeps insertion |

    bash Example session 
    cat > ~/py/stable.py <<'PY'import platformprint("floored division      :", -7 // 2)print("print is a            :", type(print).__name__)print("public str methods    :", len([m for m in dir(str) if not m.startswith("_")]))print("str.decode exists     :", hasattr(str, "decode"))print("linux_distribution    :", hasattr(platform, "linux_distribution"))print("dict keeps insertion  :", list({"z": 1, "a": 2, "m": 3}))PYpython3 ~/py/stable.pyfloored division      : -4print is a            : builtin_function_or_methodpublic str methods    : 47str.decode exists     : Falselinux_distribution    : Falsedict keeps insertion  : ['z', 'a', 'm']

    Expected result-4, a built-in function, 47 methods, no decode, no linux_distribution, and ['z', 'a', 'm'] in the order written.

    Success conditionYou can separate real changes from folklore.

  8. What to do with all of this

    Practise on whatever Python you have, and treat every "Did you mean:" as a hint you will not get on the day. Read the exception type off the last line of a traceback first, before the message, because the type is what questions ask for and it is the one part that has not changed.

    The one item to actively unlearn is the unparenthesised except, because there 3.14 and the exam genuinely disagree. Everything else on this page is a message improvement, a new warning about unchanged behaviour, or a limit on a conversion neither blueprint mentions.

    If you are choosing an interpreter from scratch, 3.12 or newer gives you the better error messages while you learn, and the single 3.14 syntax difference is one fact to remember rather than a reason to install something older.

    The orientation track ends here. guide 4 starts PCEP block 1.

    bash Example session 
    python3 --versionPython 3.14.4

    Expected resultWhatever your interpreter reports - the point is that you know which one it is.

    Success conditionYou know which differences to expect from your own Python, and which single one to answer against.

Troubleshooting

Official sources

← All PCEP guides