`TypeError: must be str, not list` when appending subtype of `str` to a `list` in uv-managed python installation on linux

[DetachHead]

Summary

this is a very strange bug because the following code only seems to crash on an uv-managed python installation and only on linux:

class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value

$ uv run python3.13
Python 3.13.3 (main, May 22 2025, 02:00:23) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(str): ...
...
... a = []
... new_value = Foo("1")
... a += new_value
...
Traceback (most recent call last):
  File "<python-input-0>", line 5, in <module>
    a += new_value
TypeError: must be str, not list

on the system version of python it works fine:

$ python3.13
Python 3.13.3 (main, Apr  9 2025, 08:55:03) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(str): ...
...
... a = []
... new_value = Foo("1")
... a += new_value
...
>>>

but on windows it works fine even, with the uv-managed python version:

> uv run python
Python 3.13.3 (main, Apr  9 2025, 04:04:49) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(str): ...
... 
>>> a = []
>>> new_value = Foo("1")
>>> a += new_value
>>>

Platform

Linux 5.15.167.4-microsoft-standard-WSL2 x86_64 GNU/Linux

Version

0.7.7

Python version

3.13.3

[harshil21]

Can confirm. If you use the python packaged with uv 0.7.5, it works fine:

uvx uv@0.7.5 python install --reinstall
Installed 2 versions in 2.46s
 ~ cpython-3.10.17-linux-x86_64-gnu
 ~ cpython-3.13.3-linux-x86_64-gnu

uv run python                          
Python 3.13.3 (main, Apr  9 2025, 04:03:52) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(str): ...
... 
>>> a = []
>>> new_value = Foo("1")
>>> a += new_value

[zanieb]

Here are some reproductions....

Working:

FROM --platform=linux/amd64 ghcr.io/astral-sh/uv:0.7.5-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.13 mre.py

Failing:

FROM --platform=linux/amd64 ghcr.io/astral-sh/uv:0.7.6-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.13 mre.py

With error:

Traceback (most recent call last):
      File "//mre.py", line 5, in <module>
        a += new_value
    TypeError: must be str, not list

The python-build-standalone distribution changes between these releases are at
astral-sh/python-build-standalone@2025040...2025051

It seems the regression is Linux-only, which makes me suspicious of
astral-sh/python-build-standalone#592 since we are not applying that on
macOS.

Note this also fails on uv v0.7.7 (the latest version).

This appears to be x86-64 specific, e.g., the following succeeds (on aarch64):

FROM --platform=linux/arm64 ghcr.io/astral-sh/uv:0.7.6-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.13 mre.py

[zanieb]

This does not reproduce on 3.14 aarch64

FROM --platform=linux/arm64 ghcr.io/astral-sh/uv:0.7.6-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.14 mre.py

[zanieb]

It does reproduce on 3.12 x86-64

FROM --platform=linux/amd64 ghcr.io/astral-sh/uv:0.7.6-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.12 mre.py

[zanieb]

Okay, and it reproduces on 3.14 x86-64

FROM --platform=linux/amd64 ghcr.io/astral-sh/uv:0.7.6-debian-slim

COPY <<EOF /mre.py
class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value
EOF

RUN uv run -p 3.14 mre.py

[Gankra]

Mitigations

uv 0.7.8 is mostly reverting python-build-standalone from 202505017 to 20250409 (the one used in uv 0.7.5).

In particular we have reverted it on non-aarch64 Linux, and also completely removed Python 3.14.0a7 to avoid portability issues between platforms. The net effect is the following changes have been defacto reverted:

• Add Python 3.14 on musl
• free-threaded Python on musl
• Add Python 3.14.0a7
• Statically link libpython into the interpreter on Linux for a significant performance boost

Future Work

We believe we have found the issue with our Python builds, and are working on testing and releasing the fix (but it's friday night on a long weekend, so we'd rather not rush out a hotfix):

• Disable unsafe identical code folding in BOLT python-build-standalone#622

Problem

On affected platforms, running the following python program with a uv-provided python would result in spurious type errors about string:

class Foo(str): ...

a = []
new_value = Foo("1")
a += new_value

Traceback (most recent call last):
  File "<python-input-0>", line 5, in <module>
    a += new_value
TypeError: must be str, not list

Affected Platforms

Here is the testing I've seen (❌ has bug, ✅ works):

• uv version (pbs version)
  • ✅ uv 0.7.8 (pbs 20250409)
  • ❌ uv 0.7.7 (pbs 20250521)
  • ❌ uv 0.7.6 (pbs 20250517)
  • ✅ uv 0.7.5 (pbs 20250409)
• os
  • ❌ linux
  • ✅ macos
  • ✅ windows
• arch
  • ❌ x86_64
  • ✅ aarch64
• python version
  • ❌ 3.12
  • ❌ 3.13
  • ❌ 3.14

Based on this testing it seemed clear that the issue was isolated to linux, and it's probably x64 specific, but I opted to handle that conservatively and just reverted "linux, not-aarch64".