Skip to content

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

Closed
#13617
Closed
TypeError: must be str, not list when appending subtype of str to a list in uv-managed python installation on linux#13610
#13617
Assignees
geofft
Labels
bugSomething isn't working

Description

@DetachHead
DetachHead
opened on May 23, 2025

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

Activity

  1. DetachHead
    added
    bugSomething isn't working
    on May 23, 2025

  2. harshil21 commented on May 23, 2025

    @harshil21
    harshil21
    on May 23, 2025

    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
  3. geofft
    self-assigned this
    on May 23, 2025

  4. zanieb commented on May 23, 2025

    @zanieb
    zanieb
    on May 23, 2025
    Member

    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

  5. zanieb commented on May 23, 2025

    @zanieb
    zanieb
    on May 23, 2025
    Member

    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

  6. zanieb commented on May 23, 2025

    @zanieb
    zanieb
    on May 23, 2025
    Member

    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

  7. zanieb commented on May 23, 2025

    @zanieb
    zanieb
    on May 23, 2025
    Member

    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
  8. geofft
    added a commit that references this issue on May 23, 2025

    Disable unsafe identical code folding in BOLT

    4adde68
  9. Gankra
    closed this as completedin #13617on May 23, 2025
  10. Gankra
    added a commit that references this issue on May 23, 2025

    blocklist the linux cpython builds from 20250517 (#13617)

    b93ce23

  11. Gankra commented on May 23, 2025

    @Gankra
    Gankra
    on May 23, 2025
    Contributor

    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):

    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".

  12. geofft
    added 3 commits that reference this issue on May 29, 2025

    Disable unsafe identical code folding in BOLT

    522bc4c

    Disable unsafe identical code folding in BOLT

    ecbcb57

    Disable unsafe identical code folding in BOLT (#622)

    cddb9c1

  13. geofft commented on Jun 1, 2025

    @geofft
    geofft
    on Jun 1, 2025
    Contributor

    uv 0.7.9, released yesterday, restores static linking of libpython but has a fix for this bug.

    If you are still seeing this, please do comment here (after double-checking that you're on the latest version of things with uv self update && uv python install --reinstall).

  14. tmeijn
    added a commit that references this issue on Jun 13, 2025

    build(deps): update astral-sh/uv to v0.7.13

    4a91a4f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions