External Publication
Visit Post

Chapter 1 questions

Hugging Face Forums [Unofficial] June 9, 2026
Source

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:

  1. the Course snippet is probably fine;
  2. your Colab session had a stale or inconsistent dependency state;
  3. the actual breakage is in the torch / torchvision / sympy import chain;
  4. 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

Loading comments...