Chapter 1 questions
Hmm, it works on my Colab environment, so maybe it’s something like this?:
I don’t think the three-line Course snippet itself is the main problem here.
This code is still a normal way to do a first Transformers smoke test:
from transformers import pipeline
classifier = pipeline("sentiment-analysis")
classifier("I’ve been waiting for a Hugging Face course my whole life.")
The current Transformers docs still describe pipeline as the high-level inference API, and the installation docs still use a pipeline("sentiment-analysis") command as an install check:
- Transformers pipelines docs
- Transformers installation check
So I would read your traceback as an environment / dependency-stack issue , not as “the Chapter 1 example is conceptually wrong”.
What looks suspicious in the traceback
The important part is not really the top-level pipeline("sentiment-analysis") line. The traceback eventually goes through something like this:
transformers
-> transformers.pipelines
-> transformers.video_utils
-> torchvision.io
-> torch._dynamo
-> torch.fx.experimental.symbolic_shapes
-> torch.utils._sympy.functions
-> sympy.printing
and then fails with:
AttributeError: module 'sympy' has no attribute 'printing'
That means the failure happens while importing the PyTorch / torchvision / SymPy-related stack. The sentiment-analysis model has not really had a chance to run yet.
In other words, this is probably closer to:
“Transformers tried to import pipeline helpers, that pulled in torchvision / PyTorch internals, and the installed PyTorch + SymPy combination was not in a clean compatible state.”
rather than:
“The sentiment-analysis pipeline example is obsolete.”
I tried a clean Colab Free CPU runtime
For comparison, I tried the same basic snippet on my Colab environment without setting an HF_TOKEN.
It worked.
My environment was:
| Package | Version |
|---|---|
| Python | 3.12.13 |
transformers |
5.9.0 |
torch |
2.11.0+cpu |
torchvision |
0.26.0+cpu |
torchaudio |
2.11.0+cpu |
sympy |
1.14.0 |
huggingface_hub |
1.17.0 |
tokenizers |
0.22.2 |
safetensors |
0.7.0 |
The output was:
[{'label': 'POSITIVE', 'score': 0.9984577894210815}]
I also saw the usual Colab warning about not having an HF_TOKEN, but that was not fatal. Public models can still be downloaded without a token, although authenticated requests may have better rate limits.
So this does not look like a general “current Colab cannot run Chapter 1” problem.
Similar known pattern
There are a few similar-looking dependency-drift cases around this area:
| Pattern | Why it is relevant |
|---|---|
| AttributeError: module 'sympy' has no attribute 'printing' | Similar failure shape: PyTorch symbolic-shape code reaches for sympy.printing and crashes. |
| pipeline import fails with torchvision::nms mismatch | Text-only pipeline usage can still fail because torchvision gets imported during the Transformers import path. |
| Failed to import transformers.pipelines ... operator torchvision::nms does not exist | Another example where from transformers import pipeline surfaces a lower-level torch / torchvision mismatch. |
| Colab past runtime FAQ | Colab runtimes and preinstalled packages change over time, which is exactly the kind of thing that can break old course notebooks or old notebook sessions. |
| Course issue: Chapter 1 notebook drift | Not the same root cause, but it shows that Course notebooks can drift as Transformers and hosted runtimes evolve. |
| Course issue: grouped_entities removed/deprecated | Another Chapter 1 drift example, though this one is about a changed pipeline argument rather than your SymPy traceback. |
The closest match to your exact traceback is the SymPy/PyTorch-looking sympy.printing problem. The closest structural match is the Transformers issues where a text pipeline fails because torchvision is imported underneath.
What I would try first
First, restart the runtime and run only the minimal snippet again.
In Colab:
Runtime -> Restart runtime
Then run:
from transformers import pipeline
classifier = pipeline("sentiment-analysis")
classifier("I’ve been waiting for a Hugging Face course my whole life.")
If that still fails, collect the versions:
import sys
import importlib.metadata as md
print("python:", sys.version)
for pkg in ["transformers", "torch", "torchvision", "torchaudio", "sympy", "huggingface_hub", "tokenizers", "safetensors"]:
try:
print(f"{pkg}: {md.version(pkg)}")
except md.PackageNotFoundError:
print(f"{pkg}: not installed")
Small workaround to test the SymPy hypothesis
Because your error is specifically:
AttributeError: module 'sympy' has no attribute 'printing'
it may be worth testing whether explicitly importing the SymPy printing submodule changes anything:
import sympy.printing
from transformers import pipeline
classifier = pipeline("sentiment-analysis")
classifier("I’ve been waiting for a Hugging Face course my whole life.")
If that works, I would treat it as an import-order / dependency-stack workaround, not as the final conceptual fix.
If the workaround does not help
Then I would try repairing the package stack.
Start small:
!pip install -U -q sympy
Then restart the runtime:
Runtime -> Restart runtime
and retry:
from transformers import pipeline
classifier = pipeline("sentiment-analysis")
classifier("I’ve been waiting for a Hugging Face course my whole life.")
If that still fails, try reinstalling the relevant stack together:
!pip install -U -q transformers torch torchvision torchaudio sympy
Then restart the runtime again.
Optional: make the model explicit
The default pipeline currently chooses a small public sentiment model automatically, but for debugging it is often nicer to be explicit:
from transformers import pipeline
classifier = pipeline(
"sentiment-analysis",
model="distilbert/distilbert-base-uncased-finetuned-sst-2-english",
)
classifier("I’ve been waiting for a Hugging Face course my whole life.")
This avoids confusing “default model selection” with the real import problem.
My current guess
My guess is:
- the Course snippet is probably fine;
- your Colab session had a stale or inconsistent dependency state;
- the actual breakage is in the
torch/torchvision/sympyimport chain; - a clean runtime, a SymPy update, or reinstalling the PyTorch-family packages together should probably fix it.
So I would not start by rewriting the Course example. I would first verify the environment versions and try a clean runtime.
Discussion in the ATmosphere