pydantic: Argument 'bases' has incorrect type
Initial Checks
- I have searched GitHub for a duplicate issue and I’m sure this is something new
- I have searched Google & StackOverflow for a solution and couldn’t find anything
- I have read and followed the docs and still think this is a bug
- I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)
Description
So last night 1.10.13 got released. And apparently it breaks on runtime,
The context is that there are some integrations in HomeAssistant that use pydantic, and they all seem to raise this issue when 1.10.13 is installed. This isn’t raised in 1.10.12 (https://github.com/home-assistant/core/pull/101044). Linked issue on the HA repo (https://github.com/home-assistant/core/issues/101042).
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/loader.py", line 818, in get_component
ComponentProtocol, importlib.import_module(self.pkg_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/usr/src/homeassistant/homeassistant/components/radio_browser/__init__.py", line 5, in <module>
from radios import RadioBrowser, RadioBrowserError
File "/usr/local/lib/python3.11/site-packages/radios/__init__.py", line 8, in <module>
from .models import Country, Language, Station, Stats, Tag
File "/usr/local/lib/python3.11/site-packages/radios/models.py", line 12, in <module>
class Stats(BaseModel):
File "pydantic/main.py", line 186, in pydantic.main.ModelMetaclass.__new__
TypeError: Argument 'bases' has incorrect type (expected list, got tuple)
Some of the libs used are https://github.com/frenck/python-vehicle and https://github.com/frenck/python-radios
Example Code
No response
Python, Pydantic & OS Version
Python 3.11
Pydantic 1.10.13
Linux
Affected Components
- Compatibility between releases
- Data validation/parsing
- Data serialization -
.model_dump()and.model_dump_json() - JSON Schema
- Dataclasses
- Model Config
- Field Types - adding or changing a particular data type
- Function validation decorator
- Generic Models
- Other Model behaviour -
model_construct(), pickling, private attributes, ORM mode - Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 24 (5 by maintainers)
Commits related to this issue
- 📌 Pin pydantic to 1.10.12 Solves #4893 by working around pydantic/pydantic#7689 — committed to OctoPrint/OctoPrint by foosel 9 months ago
- Work around pydantic/pydantic#7689 by pinning it at 1.10.12 — committed to prusa3d/Prusa-Link by TojikCZ 9 months ago
- Work around pydantic/pydantic#7689 by pinning it at 1.10.12 — committed to prusa3d/Prusa-Link by TojikCZ 9 months ago
In case it helps since (a) I spotted this issue reading the OctoPrint release notes, and (b) I just spent a some time debugging a mysterious issue with
importlibandTypeErrorthat was hard to reproduce in another Python project (https://github.com/GlasgowEmbedded/glasgow/issues/422): early Python 3.9 / especially early Python 3.10 don’t have some fixes toimportlibthat got backported, eg, around March 2022 (eg, https://github.com/python/cpython/issues/91160).In the case of the problem I was debugging (metadata
extras) the problem was are.Match()was being returned, instead of a string, it affected Python 3.9 <= 3.9.10 and Python 3.10 <= 3.10.2. Your issue is clearly slightly different (tuple instead of list, andbases) but I’d suggest considering “maybe this issue got fixed in a Pythonimportlibbackport”, and looking for a potential backport fix (I found the one affecting me viagit annotateon theimportlibfunction being called).In the Glasgow project case I initially worked around it by catching the return type received was the “wrong one” and fixing it up before using it in the Glasgow project code; but the final fix merged ended up monkeypatching in the newer code for importlib metadata
extrasonly on the old affected Python minor versions (see https://github.com/GlasgowEmbedded/glasgow/pull/436). (in the tuple / list case, you could fairly easily unconditionally force it to be a list before using it.)Ewen
I also tried running pydantic 1.10.13 inside alpine inside gitpod to use musl binaries, and again - no error.
Apparently running tests of
vehicleworks on my windows machine with 1.10.13 installed. Also triedpython-opensky.