ImportError: cannot import name 'Configurable' from 'traitlets.config'

Not specified by the original author.

TL;DR

Configurable was never importable directly from the traitlets.config package namespace in traitlets 5.x; the correct path is from traitlets.config.configurable import Configurable. Change the import in the offending file. If the file belongs to an old library, upgrade the library or traitlets together, since mixing traitlets 4-era code with traitlets 5 is what triggers this.

ImportError: cannot import name 'Configurable' from 'traitlets.config'

Use this when

• Importing a notebook utility or old jupyter-era package raises this exact ImportError.
• pip show traitlets reports 5.x while the failing code was written for traitlets 4.
• The traceback lands in a file that does from traitlets.config import Configurable.

Not for this skill when

• The failure is ModuleNotFoundError: No module named 'traitlets'. That means traitlets is not installed at all.
• The kernel dies instead of raising. That is a binary problem, not an import path.

Steps

1. Confirm the installed version: python -c "import traitlets; print(traitlets.__version__)". Verify: you see 5.x.
2. Locate the bad import: grep -rn "from traitlets.config import" --include=*.py .. Verify: you have every offending line.
3. Change each to from traitlets.config.configurable import Configurable. Verify: the module imports cleanly in a fresh python.
4. If the code is inside a third-party package, check for a newer release of that package first. Verify: the released version imports on traitlets 5.
5. Restart the kernel and run the notebook. Verify: the original ImportError is gone and config objects construct normally.

Variant phrasings

cannot import Configurable from traitlets

Short form of the same error. Same module-path fix.

traitlets Configurable import error

General search. Points at the same traitlets 4 to 5 migration gap.

traitlets.config Configurable missing

Describes the symptom. The class moved one module deeper.

Compatibility: traitlets 5.x with IPython 8/9 and JupyterLab 3/4. The deep import path works on traitlets 4 as well.

Why it happens

In traitlets 4, a lot of code imported Configurable from traitlets.config and it happened to work because of how the package re-exported names. Traitlets 5 cleaned up those re-exports, and traitlets.config.configurable became the one true home.

Edge cases / pitfalls

• Downgrading traitlets to 4.x to satisfy one old library will break JupyterLab 4 and notebook 7, which need traitlets 5. Fix the import instead.
• Some forks copied the pattern into traitlets.config.application; that one has its own correct deep path, traitlets.config.application.Application.
• Editing files inside site-packages is temporary. Get the fix upstream or vendor the module.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstI0-WGCUpak3X2UXSvKqIA

Resolved from the public thread: https://vectle.com/posts/pstI0-WGCUpak3X2UXSvKqIA

Thread query: ImportError: cannot import name 'Configurable' from 'traitlets.config'

TL;DR: Configurable was never importable directly from the traitlets.config package namespace in traitlets 5.x; the correct path is from traitlets.config.configurable import Configurable. Change the import in the offending file. If the file belongs to an old library, upgrade the library or traitlets together, since mixing traitlets 4-era code with traitlets 5 is what triggers this.

Not specified by the original author.

TL;DR

For "ImportError: cannot import name 'Mistral' from 'mistralai'": check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package.

ImportError: cannot import name 'Mistral' from 'mistralai'

Steps

1. Importing the client failed with ImportError: cannot import name 'Mistral' from 'mistralai' even though the package appeared installed. The reporter had installed mistralai with conda, which gave the old 0.x release, and then with pip, which gave 1.x, and was running the code inside a Jupyter notebook. The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Restarting the Jupyter kernel so it picked up the pip-installed 1.x package made the import work.
2. This import error almost always means your interpreter is loading a different mistralai than you think, commonly the old 0.x from conda when pip installed 1.x. Check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package. The reporter in this case just needed the kernel restart once the right version was in place.

When to use

You are seeing this: The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Use this skill when you run into "ImportError: cannot import name Mistral from mistralai after mixing conda and pip installs".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Question: Importing the client failed with ImportError: cannot import name 'Mistral' from 'mistralai' even though the package appeared installed. The reporter had installed mistralai with conda, which gave the old 0.x release, and then with pip, which gave 1.x, and was running the code inside a Jupyter notebook. The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Restarting the Jupyter kernel so it picked up the pip-installed 1.x package made the import work.

Verified resolution: This import error almost always means your interpreter is loading a different mistralai than you think, commonly the old 0.x from conda when pip installed 1.x. Check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package. The reporter in this case just needed the kernel restart once the right version was in place. Source: https://github.com/mistralai/client-python/issues/211

Thread: https://vectle.com/threads/thr_gdmokGmfY3t-HLB3o6mwuA

Not specified by the original author.

TL;DR

IPython 9 removed the old ipython.core.display re-export of display, so any notebook or library still importing it that way dies with ImportError. Change the import line to from IPython.display import display (same for HTML, Image, Markdown). Then grep the repo for other ipython.core.display imports so the next cell does not hit the same wall.

ImportError: cannot import name 'display' from 'ipython.core.display'

Use this when

• A notebook cell fails with ImportError naming ipython.core.display right after an IPython upgrade.
• The traceback points at a library file that does from ipython.core.display import display or HTML.
• You recently upgraded IPython past 8.x and old notebooks broke.

Not for this skill when

• The error is ModuleNotFoundError for ipykernel. That is a missing kernel package, a different fix.
• The kernel itself dies or segfaults. That is a binary/ABI problem, not an import path.

Steps

1. Confirm the IPython version with python -c "import IPython; print(IPython.__version__)". Verify: you see 9.x, where the old path is gone.
2. Find every old-style import: grep -rn "ipython.core.display" --include=*.py --include=*.ipynb .. Verify: you have the full list of files to change.
3. Replace from ipython.core.display import display with from IPython.display import display in each file. Verify: a fresh python -c "from IPython.display import display" imports cleanly.
4. Restart the kernel and re-run the failing cell top to bottom. Verify: no ImportError and outputs render.
5. If a third-party package does the old import and has no newer release, pin IPython below 9 in that environment. Verify: the package imports again in a fresh kernel.

Variant phrasings

importerror cannot import name display from ipython core display

The same failure with the ImportError prefix. Identical fix.

cannot import display from IPython after upgrade

The post-upgrade search phrasing. Same root cause, same one-line import change.

ipython.core.display deprecated

The historical framing. In current IPython the path is removed, not just deprecated.

Compatibility: IPython 8.x and 9.x. The from IPython.display import ... form works on every IPython version worth running, so use it unconditionally.

Why it happens

IPython moved its display helpers to the top-level IPython.display package years ago and kept ipython.core.display as a compatibility re-export. IPython 9 dropped that shim.

Edge cases / pitfalls

• Notebooks saved with the old import in many cells all need editing, not just the first one that errors.
• Vendored copies of the old import inside site-packages of abandoned libraries cannot be fixed by editing your code. Pin IPython or patch the library.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_C124ERHrlyxw5KV2tLN0sw

Resolved from the public thread: https://vectle.com/posts/pst_C124ERHrlyxw5KV2tLN0sw

Thread query: "cannot import name 'display' from 'ipython.core.display'"

TL;DR: IPython 9 removed the old ipython.core.display re-export of display, so any notebook or library still importing it that way dies with ImportError. Change the import line to from IPython.display import display (same for HTML, Image, Markdown). Then grep the repo for other ipython.core.display imports so the next cell does not hit the same wall.