Skip to content

BuildNot yet confirmed elsewhere1 publisher2 min readPublished

Dropping Python 3.10 gives library authors 3.11 features but leaves lazy imports out of reach

Python 3.15 ends support for 3.10 and adds PEP 810 lazy imports, a keyword that code supporting 3.11 cannot contain. Simon Willison can now drop 3.10 and use 3.11 features, but the plugin startup fix needs a 3.15 minimum.

The Engineer · Build desk

How we use AISend a correction

Illustration accompanying Dropping Python 3.10 gives library authors 3.11 features but leaves lazy imports out of reach
Generated illustration
Lazy imports and unpacking need a newer floor The Python version that adds each feature: asyncio's TaskGroup and timeout(), lazy imports (PEP 810) and unpacking in comprehensions (PEP 798).

Python 3.11 adds asyncio TaskGroup and timeout(). Python 3.15 adds the lazy import keyword under PEP 810 and unpacking in comprehensions under PEP 798.

Lazy imports and unpacking need a newer floor (Python version that adds each feature)
ItemValueClaim
asyncio TaskGroup and timeout()3.11 Python version10
Lazy import keyword, PEP 8103.15 Python version2
Unpacking in comprehensions3.15 Python version5

What happened

  • PEP 810 adds statements such as lazy import json and lazy from pathlib import Path, and the module loads the first time its symbols are used.
  • Unpacking in comprehensions, from PEP 798 by Adam Hartz and Erik Demaine, adds the spelling [*sublist for sublist in lists].
  • Miguel Grinberg found 3.15.0rc3 mostly as fast as 3.14, except for the experimental JIT, which ran 1.2x faster on a Fibonacci test.
  • Willison says Datasette makes extensive use of asyncio, where 3.11 adds TaskGroup and timeout().

Why it matters

  • cost Users of plugins with heavy dependencies keep paying the import time on every run until plugin authors can require 3.15.
  • decision A maintainer chooses between the 3.11 floor open today and a 3.15 floor that unlocks both new syntaxes.
  • capability A library that waits for 3.15 gives up a shorter way to flatten nested lists and sets and to merge dicts, and loses no capability.

The deferral targets a specific cost. Willison builds the LLM CLI tool, which has plugins. Installing a plugin with a heavy dependency such as `sentence_transformers` could add multiple seconds to every invocation of the `llm` command, so his plugin author documentation recommends manual lazy imports [3]. Of the new keyword he wrote, "Lazy imports directly address this startup cost." [4]

The catch is the version floor. The `lazy import` statement is new in 3.15 [2]. Willison's floor after dropping 3.10 is 3.11 [8]. That floor sits four minor releases below the syntax [14], and a library that supports 3.11 cannot use the keyword, so it keeps the manual workaround [13]. Comprehension unpacking is also 3.15 syntax and falls under the same floor [15].

A 3.11 floor buys standard-library features. Willison wrote, "I finally get to rely on tomllib being available!" [9]

Comprehension unpacking is a convenience. The 3.15 documentation gives each form a plain equivalent: `[*L for L in lists]` matches `[x for L in lists for x in L]`, and sets and dicts get matching forms [6]. PEP 798 extends the unpacking syntax of PEP 448, which landed in 3.5 in 2015 [5].

Treat the JIT figure as a claim about a Fibonacci workload. It comes from compute-bound code [7]. For it to transfer, your program would have to spend most of its time executing Python in hot loops. A command that loses seconds to importing `sentence_transformers` loses them at startup [3].

Trying 3.15 is cheap. uv has to learn about the release first, so Willison ran `uv self update`, then `uv python install 3.15` [11]. His global pin, `uv python pin --global 3.15`, yields to any project that pins its own version [12].

What to watch

  • Whether the LLM plugin author documentation changes its manual lazy-import advice once projects can require 3.15.
  • JIT benchmarks on 3.15 that use workloads with real import time instead of a Fibonacci test.
  • Whether Willison's main projects publish releases that set 3.11 as the minimum version.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence70
Adoption10
Hype gap+10
Incentives
Insufficient
Confidence60
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    With the release of Python 3.15, Python 3.10 (released in 2021) is officially no longer supported.

    ReportedSupportedSource: Simon Willison, simonwillison.net, 12 October 2026View cited source
  2. [2]

    Python 3.15 adds explicit lazy imports under PEP 810, written as `lazy import json` or `lazy from pathlib import Path`; the module is imported the first time those symbols are used in the code that follows.

    ReportedSupportedSource: Simon Willison, simonwillison.netView cited source
  3. [3]

    Willison's LLM CLI tool implements plugins, and he had to recommend manual lazy imports in the plugin author documentation, because simply installing plugins that used heavy dependencies such as sentence_transformers could add multiple seconds to every invocation of the llm command.

    ReportedSupportedSource: Simon Willison, simonwillison.netView cited source

Sources

1 independent publisher whose own reporting we read for this story.

  1. simonwillison.net

    1 article · October 12, 2026

    Hello Python 3.15, goodbye 3.10, and now I can use 3.11

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

  • Python releasesFollow
  • Python packaging and toolingFollow
  • Library version compatibilityFollow

Entities

Loading related stories