Expected string or bytes like object python ошибка

  TypeError

  expected string or bytes-like object

  at /usr/local/lib/python3.8/site-packages/poetry/core/utils/helpers.py:24 in canonicalize_name

Creating virtualenv amp-portal in /__w/backend/backend/amp-portal/.venv
Using virtualenv: /__w/backend/backend/amp-portal/.venv

  Stack trace:

  11  /usr/local/lib/python3.8/site-packages/clikit/console_application.py:131 in run
       129│             parsed_args = resolved_command.args
       130│ 
     → 131│             status_code = command.handle(parsed_args, io)
       132│         except KeyboardInterrupt:
       133│             status_code = 1

  10  /usr/local/lib/python3.8/site-packages/clikit/api/command/command.py:120 in handle
       118│     def handle(self, args, io):  # type: (Args, IO) -> int
       119│         try:
     → 120│             status_code = self._do_handle(args, io)
       121│         except KeyboardInterrupt:
       122│             if io.is_debug():

   9  /usr/local/lib/python3.8/site-packages/clikit/api/command/command.py:163 in _do_handle
       161│         if self._dispatcher and self._dispatcher.has_listeners(PRE_HANDLE):
       162│             event = PreHandleEvent(args, io, self)
     → 163│             self._dispatcher.dispatch(PRE_HANDLE, event)
       164│ 
       165│             if event.is_handled():

   8  /usr/local/lib/python3.8/site-packages/clikit/api/event/event_dispatcher.py:22 in dispatch
        20│ 
        21│         if listeners:
     →  22│             self._do_dispatch(listeners, event_name, event)
        23│ 
        24│         return event

   7  /usr/local/lib/python3.8/site-packages/clikit/api/event/event_dispatcher.py:89 in _do_dispatch
        87│                 break
        88│ 
     →  89│             listener(event, event_name, self)
        90│ 
        91│     def _sort_listeners(self, event_name):  # type: (str) -> None

   6  /usr/local/lib/python3.8/site-packages/poetry/console/config/application_config.py:141 in set_installer
       139│ 
       140│         poetry = command.poetry
     → 141│         installer = Installer(
       142│             event.io,
       143│             command.env,

   5  /usr/local/lib/python3.8/site-packages/poetry/installation/installer.py:65 in __init__
        63│         self._installer = self._get_installer()
        64│         if installed is None:
     →  65│             installed = self._get_installed()
        66│ 
        67│         self._installed_repository = installed

   4  /usr/local/lib/python3.8/site-packages/poetry/installation/installer.py:561 in _get_installed
       559│ 
       560│     def _get_installed(self):  # type: () -> InstalledRepository
     → 561│         return InstalledRepository.load(self._env)
       562│ 

   3  /usr/local/lib/python3.8/site-packages/poetry/repositories/installed_repository.py:118 in load
       116│                 path = Path(str(distribution._path))
       117│                 version = distribution.metadata["version"]
     → 118│                 package = Package(name, version, version)
       119│                 package.description = distribution.metadata.get("summary", "")
       120│ 

   2  /usr/local/lib/python3.8/site-packages/poetry/core/packages/package.py:51 in __init__
        49│         Creates a new in memory package.
        50│         """
     →  51│         super(Package, self).__init__(
        52│             name,
        53│             source_type=source_type,

   1  /usr/local/lib/python3.8/site-packages/poetry/core/packages/specification.py:19 in __init__
        17│     ):  # type: (str, Optional[str], Optional[str], Optional[str], Optional[str], Optional[List[str]]) -> None
        18│         self._pretty_name = name
     →  19│         self._name = canonicalize_name(name)
        20│         self._source_type = source_type
        21│         self._source_url = source_url

  TypeError

  expected string or bytes-like object

  at /usr/local/lib/python3.8/site-packages/poetry/core/utils/helpers.py:24 in canonicalize_name
       20│ _canonicalize_regex = re.compile("[-_]+")
       21│ 
       22│ 
       23│ def canonicalize_name(name):  # type: (str) -> str
    →  24│     return _canonicalize_regex.sub("-", name).lower()
       25│ 
       26│ 
       27│ def module_name(name):  # type: (str) -> str
       28│     return canonicalize_name(name).replace(".", "_").replace("-", "_")

ARG DEBIAN_VERSION=buster
ARG PYTHON_VERSION=3.8
FROM python:${PYTHON_VERSION}-slim-${DEBIAN_VERSION}

ENV 
    DEBIAN_FRONTEND=noninteractive 
    PYTHONUNBUFFERED=1 
    PYTHONDONTWRITEBYTECODE=1 
    POETRY_VIRTUALENVS_IN_PROJECT=true 
    POETRY_NO_INTERACTION=1

RUN set -x 
    && apt-get update 
    && apt-get install -yq --no-install-recommends libpq-dev build-essential sudo 
    && rm -rf /var/lib/apt/lists/*

RUN pip install poetry==1.1.4

We should try to narrow it down, maybe there is a dependency somewhere with packaging issues.

Some extra information:

• we use a GHES installation with multiple runners. On some runners it fails every time, on others it always succeeds.
• this is not dependent on the local .venv directory: that is newly created on every run
• it is not dependent on what is in the users home directory: that is part of the docker container and is identical on all runners.

So there is something very specific to a runner that is independent from the docker image that triggers this error.

I see. This is good info. This changes my perspective on this issue.

Perhaps this could be a broken cache entry somewhere?

I’m adding @netcaptors here; he is a member of the team that manages the github runners and has more insight into their configuration than I have.

I’m out of my depth on this. I’ll ping @stephsamson and @finswimmer maybe they’ll be able to give more insight or redirect to other maintainers.

But you seem to say it’s rather new behaviour, although there was no new poetry release in a while, right?

This particularly error is new for us today as far as I can tell. I expect that there is something in the environment that poetry needs to deal with that changed and triggered this error.

Doubtful, we had not done a rebuild of our docker image at the moment this error started occurring as far as I know.

As magically as this error started appearing, it seems to have disappeared today. As far as I know the only change that happened is that chmod -R github-runner:github-runner /home/github-runner/runner/_work/ was run on the runner instance that was showing the error. The best theory I have is that there was a directory or file somewhere that was not readable by the user, which triggered this error. Perhaps a .dist-info directory that was not readable?

I saw this issue locally today on my mac. I used poetry 1.1.4 and it worked for me until today, for some reason, poetry install doesn’t work and reported the same error in this issue. Commands like poetry show stops working too with the same error.

I tried revert everything to a specific git commit I confirmed working recently (delete the entire folder and fetch from git again, so it doesn’t seem to me a permission issue), but the same error was reported.

I got the same problem. I dropped into PDB and tried to track it down.

name is None and it comes from here:

https://github.com/python-poetry/poetry/blob/1.1.4/poetry/repositories/installed_repository.py#L115

Then if I run this in PDB:
pp [x.metadata["Name"] for x in metadata.distributions(path=[env.sys_path[4]])]

I get for my specific .venv/project I get something like:

[ '...',
 'dbus-python',
 None,
 'pluggy',
 'flake8',
 '...']

Note the None.

Now let’s find the culprit:
pp [x.files if x.metadata["name"] is None else "SKIP" for x in metadata.distributions(path=[env.sys_path[4]])]

[ '...',
 'SKIP',
 [PackagePath('more_itertools-8.7.0.dist-info/INSTALLER'),
  PackagePath('more_itertools-8.7.0.dist-info/LICENSE'),
  PackagePath('more_itertools-8.7.0.dist-info/METADATA'),
  PackagePath('more_itertools-8.7.0.dist-info/RECORD'),
  PackagePath('more_itertools-8.7.0.dist-info/REQUESTED'),
  PackagePath('more_itertools-8.7.0.dist-info/WHEEL'),
  PackagePath('more_itertools-8.7.0.dist-info/direct_url.json'),
  PackagePath('more_itertools-8.7.0.dist-info/top_level.txt'),
  PackagePath('more_itertools/__init__.py'),
  PackagePath('more_itertools/__init__.pyi'),
  PackagePath('more_itertools/__pycache__/__init__.cpython-39.pyc'),
  PackagePath('more_itertools/__pycache__/more.cpython-39.pyc'),
  PackagePath('more_itertools/__pycache__/recipes.cpython-39.pyc'),
  PackagePath('more_itertools/more.py'),
  PackagePath('more_itertools/more.pyi'),
  PackagePath('more_itertools/py.typed'),
  PackagePath('more_itertools/recipes.py'),
  PackagePath('more_itertools/recipes.pyi')],
 'SKIP',
 '...']

For some reason PathDistribution object representing more_itertools package has empty metadata and version fields.

Interestingly enough it’s also the only dependency of my project dependencies which upgraded when I last ran poetry update. Not sure if that’s related, or they broke something.

Hope this helps.

EDIT:
I actually checked the METADATA file in more_itertools-8.7.0.dist-info directory and it’s empty.

Extra info:
pip version in venv: 21.0.1
pip version outside: 20.3.3
poetry version: 1.1.4

EDIT 2:
I bet it has something to do with pip version as mentioned before.

EDIT 3:
I ended up having to clear ~/.cache/pypoetry seems like the whole artifact was corrupted. Without that even deleting and reinstalling .venv would crash on poetry install.

I was also having the same problem.

In my case, I ran poetry shell to test out running pyInstaller command inside the shell. Once I exited the shell and tried to run command poetry run or poetry install, I got expected string or bytes-like object error message.

MaikuMori’s third solution, removing ~/.cache/pypoetry did the trick and solved the issue.

Update:
Removing ~/.cache/pypoetry did work temporarily. The first command either poetry install or poetry run will work, but on subsequent command still got the same error message. To get around it, remove the cache then run poetry command again and keeps repeating the cycle.

We also get those expected string or bytes-like object a lot, but we are working in a conda environment on MacOS. For us, it seems to happen more often when we are changing branch in our soft repo, then doing a poetry install, or when updating a dependency to use the path directive ('toto' = {path='<some-path>', develop=true}), for version. Unfortunately, I didn’t find a way to consistently reproduce those errors.

First, I start with a pyenv-installed python-3.8.8:

$ pyenv install 3.8.8
$ pyenv global 3.8.8

I try to reproduce the problem after a fresh installation of poetry-1.1.5:

$ mkdir debug
$ cd debug
$ poetry new somepackage
$ cd somepackage
$ poetry install # This creates the virtual environment in ~/.cache/pypoetry/virtualenvs

  TypeError

  expected string or bytes-like object

  at ~/.poetry/lib/poetry/_vendor/py3.8/poetry/core/utils/helpers.py:27 in canonicalize_name
       23│ _canonicalize_regex = re.compile(r"[-_]+")
       24│ 
       25│ 
       26│ def canonicalize_name(name):  # type: (str) -> str
    →  27│     return _canonicalize_regex.sub("-", name).lower()
       28│ 
       29│ 
       30│ def module_name(name):  # type: (str) -> str
       31│     return canonicalize_name(name).replace(".", "_").replace("-", "_")

Now, I inspect the newly-created virtual environment’s site-packages

$ cd ~/.cache/pypoetry/virtualenvs/somepackage-RAiBNyBV-py3.8/lib/python3.8/site-packages
$ ls -al

total 44K
drwxr-xr-x 2 myuser mygrp 4.0K Apr  7 09:23 _distutils_hack
drwxr-xr-x 4 myuser mygrp 4.0K Apr  7 09:23 pip
drwxr-xr-x 5 myuser mygrp 4.0K Apr  7 09:23 pkg_resources
drwxr-xr-x 2 myuser mygrp 4.0K Apr  7 09:23 __pycache__
drwxr-xr-x 6 myuser mygrp 4.0K Apr  7 09:23 setuptools
drwxr-xr-x 4 myuser mygrp 4.0K Apr  7 09:23 wheel
drwxr-xr-x 2 myuser mygrp 4.0K Apr  7 09:23 pip-21.0.1.dist-info
drwxr-xr-x 2 myuser mygrp 4.0K Apr  7 09:23 setuptools-52.0.0.dist-info
drwxr-xr-x 2 myuser mygrp 4.0K Apr  7 09:23 wheel-0.36.2.dist-info
-rw-r--r-- 1 myuser mygrp    0 Apr  7 09:23 distutils-precedence.pth
-rw-r--r-- 1 myuser mygrp   18 Apr  7 09:23 _virtualenv.pth
-rw-r--r-- 1 myuser mygrp 5.6K Apr  7 09:23 _virtualenv.py
-rw-r--r-- 1 myuser mygrp    0 Apr  7 09:23 pip-21.0.1.virtualenv
-rw-r--r-- 1 myuser mygrp    0 Apr  7 09:23 setuptools-52.0.0.virtualenv
-rw-r--r-- 1 myuser mygrp    0 Apr  7 09:23 wheel-0.36.2.virtualenv

They seem to be empty, even the pip folder has zero-length files:

$ ls -al pip
total 8.0K
drwxr-xr-x 13 myuser mygrp 4.0K Apr  7 09:23 _internal
drwxr-xr-x 19 myuser mygrp 4.0K Apr  7 09:23 _vendor
-rw-r--r--  1 myuser mygrp    0 Apr  7 09:23 __init__.py
-rw-r--r--  1 myuser mygrp    0 Apr  7 09:23 __main__.py

Is this intentional?

I did all of this using previous poetry versions (1.1.0 and 1.1.4 if I remember correctly). I see the same behavior.

I see empty site-packages if I use:

• pyenv installed python
• python that I compiled myself

site-packages are populated if I use the system python.

The rubber ducky problem solving method has been demonstrated. Writing down my problem in #3628 (comment) has helped a lot in framing it.

This is what I did to get around the problem of empty site-packages

# system python is only 3.7. I need 3.8.
$ pyenv install 3.8.8
$ pyenv versions
* system (set by ~/.pyenv/version)
  3.8.8

# Use system python to do all the poetry initialization
$ pyenv global system
$ python --version
Python 3.7.3

$ mkdir debug
$ cd debug
$ poetry new somepackage
$ cd somepackage
$ poetry env use ~/.pyenv/versions/3.8.8/python
$ poetry install
$ poetry shell
$ python --version
Python 3.8.8

That should do it.

I’ve stumbled into the same issue today, seemingly out of the blue. This morning I did a system upgrade (pacman -Syu) and after the first poetry install the message started appearing.

I had used pyenv to use Python 3.7.8. I tried clearing the cache and recreating the venv, but no luck. I then tried the system Python to create the venv (Python 3.9.2), but same thing.

I could run poetry update repeatedly in a clean environment, but after the first run of poetry install the message appears every time (even on poetry update).

I then tried installing another project, which worked fine. Then I tried installing the old project (https://github.com/ActivityWatch/aw-client) again, which gave the output:

Installing dependencies from lock file

Package operations: 9 installs, 0 updates, 0 removals

  • Installing lazy-object-proxy (1.6.0)
  • Installing wrapt (1.12.1)
  • Installing astroid (2.5.3)
  • Installing coverage (5.5)
  • Installing isort (5.8.0)
  • Installing mccabe (0.6.1)
  • Installing pylint (2.7.4)
  • Installing pytest-cov (2.11.1)
  • Installing tabulate (0.8.9)

Installing the current project: aw-client (0.3.1)

I assume one of these dependencies are to blame, but I don’t know which (and yes, they are all up to date).

Edit: Weirdly enough the same issue doesn’t seem to occur in CI (ActivityWatch/aw-client#56), so perhaps one of the dependencies aren’t to blame after all? Or it’s just that poetry install or similar is never ran twice…

Edit: The issue ended up being the .egg-link directories that were in various places in my project. I deleted them, and now no issues!

Found them all with: find . -maxdepth 2 | grep .egg-info

I’m not sure if this is useful, but I was having this issue when deploying via Docker to Digital Ocean App Platform. I changed my Docker image base as such:

from:

FROM python:3.8.1-slim-buster

to:

In my case poetry fails with a similar error when I’m trying to add a package:

poetry add "git+https://github.com/streamlit/streamlit.git#0.81.2.dev20210506"

I am not sure if it has anything to do with what you guys are experiencing but after get this problem localy in serveral projects and find this issue I started to debug poetry and found out that the issue was happening because, for some reason, I had a .egg-info directory. I could than see that poetry was checking on it for installed packages and there was a distribution object with no name in its metadata.

Reproducing the error: (I dont know how it would behave with a valid .egg-info directory)

# Working as expected
~/open-offertator$ poetry install
Installing dependencies from lock file

No dependencies to install or update

Installing the current project: open_offertator (0.1.0)

# Create a .egg-info directory
~/open-offertator$ mkdir open_offertator.egg-info/

# Try poetry again
~/open-offertator$ poetry install

  TypeError

  expected string or bytes-like object

  at ~/.pyenv/versions/3.9.4/lib/python3.9/site-packages/poetry/core/utils/helpers.py:27 in canonicalize_name
       23│ _canonicalize_regex = re.compile(r"[-_]+")
       24│ 
       25│ 
       26│ def canonicalize_name(name):  # type: (str) -> str
    →  27│     return _canonicalize_regex.sub("-", name).lower()
       28│ 
       29│ 
       30│ def module_name(name):  # type: (str) -> str
       31│     return canonicalize_name(name).replace(".", "_").replace("-", "_")

I hope it helps.

I have a minimal reproduction pyproject.toml file that may be the same issue. I was trying to add a spacy model directly to my deps (the en-core-web-sm line below), but I ultimately had to specify it as a URL dep to get poetry.lock to generate.

[tool.poetry]
name = "failure-to-install"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]

[tool.poetry.dependencies]
python = "^3.9"
en-core-web-sm = { git = "https://github.com/explosion/spacy-models", tag = "en_core_web_sm-3.0.0" }

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Hope this helps!

This has nothing to do with anaconda, I’ve had this without using anaconda.

#3628 (comment)

For some of us, it is directly due to anaconda.

I am currently facing this without anaconda (actually deactivated an anaconda env beacuse of some comments above) on pure venv. Still no recourse.
poetry install works fine the first time,
but the second time around, fails with this errorm which is really bizarre.

Did you try reinstalling poetry, making sure your anaconda environment wasn’t active during install? I’d use the same python binary whenever you run poetry commands.

For some of us, it is directly due to anaconda.

It looks like it triggers the bug, but there are other triggers too.

For some reason, the download is corrupted, which then corrupts the cache. Without clearing the cache, it will continue to install the corrupted version.

And by corrupted I mean the METADATA file being empty for the package.

For me it was related to the .venv folder created by poetry:

👉 Deleting that folder and running poetry update worked for me 😄 .

I’m using pyenv and poetry with the pyenv-virtualenv extension.
Along the lines of @Matesanz ‘s solution,

pyenv virtualenv-delete <offending-venv>
pyenv virtualenv <python-version> <offending-venv>
poetry install

worked for me.

What worked for me:
poetry env list --full-path which returns path
rm -rf path
poetry update
For me, the issue was triggered by installing from a git URL, which worked initially and then became corrupted. I was only using poetry, not conda and only using pip implicitly.

Even after deleting the .venv, poetry install or poetry update continues to give me this

  TypeError

  expected string or bytes-like object

Try deleting the poetry.lock also before the poetry install and update

I’m not sure why you’d use poetry with anaconda? Poetry is an environment manager for virtual envs, why would you make a conda environment too? In my case, I had previously used anaconda environments and use them for some old projects still, while now having migrated solely to poetry. I just needed to switch out of that old anaconda env when switching to a separate poetry managed project.

Because we have as deps some software available only in conda and not pypi (and they won’t be), but we can still use a big part without the need for a conda environment.
Plus, were I work, it is used to handle all aspect of the development (like publishing the package to a private pypi, handling the dependencies, etc), not just the environment (on which it can causes us some trouble when we have to work with conda).

@aalok-sathe You are running poetry inside a conda environment ? If yes, you can try to run the following snippet:

from os import environ, remove, rmdir
from shutil import rmtree
from sys import version_info

import importlib_metadata as metadata

MODULES_PATH = [
    f"{environ['CONDA_PREFIX']}/lib/python{version_info.major}.{version_info.minor}/site-packages",
    f"{environ['HOME']}/.local/lib/python{version_info.major}.{version_info.minor}/site-packages",
]

if __name__ == '__main__':
    for pkg in filter(lambda a: a.metadata["name"] is None, metadata.distributions(path=MODULES_PATH)):
        print("Erasing", pkg._path)
        if pkg._path.is_dir():
            rmtree(pkg._path)
        else:
            remove(pkg._path)

(I’ve already posted it, but can’t recall in which issue).

The TypeError «expected string or bytes-like object» appears to obscure various kinds of issues people posted here. It’d be great if the actual underlying root causes can be surfaced instead.

In my case, I ran into the issue in the following combination:

1. create and use a conda env
2. use poetry install to install package A from source.
3. use poetry install to install package B from source.

TypeError is encountered in installing package B.

I later realize doing poetry install on multiple packages in a single conda environment is probably problematic, if not outright unsupported. If that’s indeed the case, it’d be great if a more explicit error is raised instead.

Still getting this error on Poetry 1.1.13. I have no .egg-info folders anywhere. Deleting my virtual environment is not an option. I have several stubs there that need to stay in place and re-installing my large project every single time this happens is not reasonable.

Still getting this error on Poetry 1.1.13. I have no .egg-info folders anywhere. Deleting my virtual environment is not an option. I have several stubs there that need to stay in place and re-installing my large project every single time this happens is not reasonable.

The fix is in Poetry 1.2b2 — Poetry 1.1.x is not seeing releases as we work up to a full release of 1.2.

Still getting this error on Poetry 1.1.13. I have no .egg-info folders anywhere. Deleting my virtual environment is not an option. I have several stubs there that need to stay in place and re-installing my large project every single time this happens is not reasonable.

The fix is in Poetry 1.2b2 — Poetry 1.1.x is not seeing releases as we work up to a full release of 1.2.

Yup. Discovered that after commenting about your poor documentation.

For me, version 1.2.0b2 found multiple kiwisolver .dist-info folders in my site-packages. One for an older version and one for the latest. I had no .egg-info folders anywhere, so I think this was the culprit.

Still getting this error on Poetry 1.1.13. I have no .egg-info folders anywhere. Deleting my virtual environment is not an option. I have several stubs there that need to stay in place and re-installing my large project every single time this happens is not reasonable.

The fix is in Poetry 1.2b2 — Poetry 1.1.x is not seeing releases as we work up to a full release of 1.2.

Yup. Discovered that after commenting about your poor documentation.

Poetry is free software developed by volunteers without any expectation of warranty. I am sorry that you had to struggle to find the relevant documentation, and I will make a note of improving it before release. Note that we are still in beta for 1.2 and things are therefore still in flux. Please refrain from using an unnecessarily hostile or confrontational tone.

For me, version 1.2.0b2 found multiple kiwisolver .dist-info folders in my site-packages. One for an older version and one for the latest. I had no .egg-info folders anywhere, so I think this was the culprit.

I’m glad you were able to sort the issues out. Please test 1.2 in your environment and open issues for any regressions or deficiencies (like documentation) you may find.

Apologies, my frustration came out and that was unprofessional. I appreciate your help. Thank you for responding so quickly.

I tried using 1.2.0rc1 and it fails a different way so I can’t tell if it fixes the name problem. It’s in a similar area of code and has the same kind of feel, so I figured I’d at least mention it here since I really don’t have time to open a whole new ticket:

  • Updating certifi (2021.10.8 /Users/kentpitman/Library/Caches/pypoetry/artifacts/61/99/d0/9b77a70db9834d3d8281903159311224b92e6ac1cdab98dca7f6367740/certifi-2021.10.8-py2.py3-none-any.whl -> 2022.6.15): Failed

  AssertionError

  

  at fsenv/lib/python3.7/site-packages/poetry/utils/env.py:343 in find_distribution_files_with_name
       339│     ) -> Iterable[Path]:
       340│         for distribution in self.distributions(
       341│             name=distribution_name, writable_only=writable_only
       342│         ):
    →  343│             assert distribution.files is not None
       344│             for file in distribution.files:
       345│                 if file.name == name:
       346│                     yield Path(
       347│                         distribution.locate_file(file),  # type: ignore[no-untyped-call]

That assertion does behave helpfully because it stops everything dead in its tracks. Is it really that fatal? I would think it would be less disruptive to merge lines 343 and 344 as

for file in distribution.files or []:  # sometimes distribution.files is None

possibly adding a log.warning if you want someone to know about the problem? Putting assert in production code seems iffy. I thought that was only for testing.

if you care then raise a new ticket and say how to reproduce, no point in making updates in unrelated and already-closed issues

Definitely do open a new issue if you can reproduce this consistently in a container/VM.

With regard to assert in production code, it’s there for typing purposes and is very helpful for catching this kind of bug. It should be impossible for a None to sneak in there according to the intention of the authors of that section of code, and yet it happened — this is why typing (and typing asserts) are very helpful for writing robust Python code.

I’ll try to open a ticket if I get time, but as you probably know, it takes time to do a good ticket that isn’t overly complicated. It helps to know that you think this is not a known problem, since that makes the investment in time seem more justified. Thanks.

Still experience this

This is a closed issue that could refer to a wild assortment of different root causes — if you are running into this, please narrow it down to a minimal reproduction and open an issue so we can try to understand how to solve it.