AttributeError: Module 'Collections' Has No Attribute 'Iterable'

This error appears when code imports Iterable from collections on Python 3.10+, and you fix it by importing from collections.abc instead.

What AttributeError: Module ‘Collections’ Has No Attribute ‘Iterable’ Means

The message attributeerror: module ‘collections’ has no attribute ‘iterable’ tells you that Python can no longer find the Iterable abstract base class inside the collections module. Older code used to import Iterable and other abstract types from collections, but modern Python keeps those types in a separate collections.abc module.

This change affects projects that still rely on the older import style. When such code runs on Python 3.10 or later, the runtime searches collections for Iterable, finds nothing, and raises the AttributeError you see in the traceback. The code itself might be yours, or it might live inside a third party package that has not yet adjusted for the newer layout.

Once you understand that the class still exists but moved to a different home, the fix becomes clear. You either update the import statement in your own source files or point your setup to a library version that already imports from collections.abc.

Why Attributeerror: Module ‘Collections’ Has No Attribute ‘Iterable’ Appears In Modern Python

Python shifted the abstract base classes for container types some time ago. These classes now live in collections.abc, and the temporary alias inside collections vanished in Python 3.10. Code that still expects the alias to exist now fails, while the rest of the language behaves as before.

Several related names moved along with Iterable. Classes such as Mapping, MutableMapping, Sequence, MutableSequence, and Generator also sit under collections.abc in current releases. Any import that pulls these names directly from collections risks the same type of crash on recent interpreters.

Python 3.8 and 3.9 — The alias in collections still exists but carries a deprecation note in the release logs.
Python 3.10 and later — The alias disappears, so imports that rely on collections.Iterable fail with an AttributeError.
Projects tied to old Python — Code written only for 3.5 or 3.6 often still uses the older import style, so it breaks once you upgrade the runtime.

Because of this history, this AttributeError behaves like a signal that your code, or one of your dependencies, still assumes the older layout of container base classes.

Quick Checks Before You Change Any Code

Fast checks: Run a few small checks before you start editing files. This helps you confirm where the error comes from and whether it sits in your own project or in a third party package.

Note the traceback path — Read the last stack frames to see which file mentions collections.Iterable. If it is a site-packages path, the issue likely comes from a dependency.
Print the Python version — Run python -V or python3 -V to see if you are on 3.10 or a later release.
Search your project — Use your editor search for the text from collections import Iterable or collections.Iterable.

If the search finds matches only inside your own source tree, you can fix the imports directly. When the matches live under site-packages, the safer path is to upgrade or pin the package instead of editing vendor code in place.

Python Version	collections.Iterable	Recommended Action
3.7 or earlier	Still present for legacy reasons	Plan to switch to collections.abc when you upgrade
3.8–3.9	Works but no longer encouraged	Update imports now to avoid later breakage
3.10 or later	Removed from collections	Replace every reference with collections.abc.Iterable

Fixing Your Own Code With collections.abc

Direct fixes: When the error comes from files you control, the repair usually requires only a handful of small edits. You switch imports to collections.abc and, in some cases, adjust isinstance checks to reflect the new names.

Switch To The New Import Path

Most broken snippets import Iterable directly from collections. A common pattern looks like this small example with type checks around a function argument.

from collections import Iterable

def flatten(items):
    if isinstance(items, Iterable):
        for value in items:
            yield from flatten(value)
    else:
        yield items

On Python 3.10 and later, that import line fails. The fix replaces the import with a collections.abc version and keeps the rest of the function unchanged.

from collections.abc import Iterable

def flatten(items):
    if isinstance(items, Iterable):
        for value in items:
            yield from flatten(value)
    else:
        yield items

You can apply the same pattern for other abstract base classes. Imports such as from collections import Mapping or from collections import MutableSequence now become imports from collections.abc instead.

Keep Code Working On Old And New Python

Some projects still run on a range of Python releases. In that case you might prefer a small compatibility shim that hides the import change behind a single shared name.

try:
    from collections.abc import Iterable
except ImportError:
    from collections import Iterable  # older Python

This pattern lets the same source tree run on a wider span of versions. New interpreters take the top branch, and older ones fall back to the second import. You can place this snippet in a dedicated helpers module and import Iterable from there in the rest of your code.

Fixing Third Party Libraries That Still Use collections.Iterable

Library fixes: When the stack trace points into site-packages, you have several options. Editing files inside installed packages can work during quick experiments, but long term you want a versioned fix that survives upgrades and new deployments.

Upgrade the package — Check whether a newer release already switched to collections.abc. Many widely used libraries adjusted their imports once Python 3.10 arrived.
Pin a compatible Python release — In some setups you can run code under Python 3.9 for a while until the library catches up. This keeps your stack stable while you wait for an upstream patch.
Maintain a local fork — If you rely on the project heavily and it no longer sees active maintenance, you can create a fork, adjust the imports, and point your installer to that fork.

If you decide to patch the installed files directly, keep a record of the changes. A hidden AttributeError disappearing without a trail can confuse teammates or you later when a clean install recreates the crash.

Spot Common Legacy Imports In Dependencies

Several packages reuse the same patterns. When auditing a stack, scan for these forms inside site-packages, as they often break together on a Python upgrade.

Legacy Iterable checks — Lines that call isinstance(obj, collections.Iterable).
Deprecated mapping imports — Imports of Mapping, MutableMapping, or MappingView from collections.
Sequence base classes — Imports that reference Sequence or MutableSequence through collections.

Each of these patterns can be adjusted to pull from collections.abc instead. Once the imports move, the code runs cleanly on new Python releases while still behaving as before.

Preventing This Error On New Projects

Forward fixes: After you repair the current crash, it helps to add a few habits that keep similar issues away from new code. The same ideas also guard against related changes in later Python releases.

Always import abstract types from collections.abc — Treat that module as the sole source of Iterable, Mapping, Sequence, and related names.
Run tests on more than one Python version — A simple matrix in your continuous integration setup quickly reveals breakage that appears only on newer interpreters.
Watch deprecation notes in release logs — When a change notes that a name will move or vanish in a later release, update your code on a branch while you still have time.

Small habits like these keep your stack closer to current patterns in the Python world. The less your project leans on legacy aliases, the lower the odds that a new interpreter removes a name you rely on.

Many users first meet this message while installing or running tools through pip. The package itself may still work on older interpreters, but once the global Python version jumps forward, the same wheel can misbehave. Seeing the problem during an install step does not always mean pip itself is broken; the underlying project usually just has an outdated import.

During day to day work it helps to read tracebacks from the bottom upward. The final lines describe the deepest call that failed, and the earlier lines show how control reached that point. Once you get used to this pattern, spotting the actual file and line that trigger the AttributeError becomes much simpler.

When you upgrade a large project, try to run its test suite as soon as the new interpreter is active. Failing tests that mention collections.Iterable give you a fast inventory of the spots that still need attention. Even a small set of smoke tests, such as starting the main entry point and running one or two commands, can reveal this crash early in the process.

If your editor supports multi file search and replace, you can use it to work through a whole code base. First search for any use of collections.Iterable with case sensitive matching. Then replace the import lines while leaving comments and string literals alone. Review each match before you apply edits in bulk so that your changes stay focused on real code.

Some teams like to place abstract imports in a shared typing or utils module. With this pattern you update the mapping between the concrete import and the shared name once, and every consumer picks up the change on the next run. That kind of central point also makes it easy to switch away from a deprecated name long before it vanishes from the language.

On large stacks you might have both application code and libraries under active development. When you prepare a release that targets a new Python version, try to upgrade core dependencies on a branch first. Run their own changelogs and test commands, then merge your branch only when the upgraded packages and your code play well together.

Tooling can help as well. Linters and type checkers can flag legacy imports and guide you toward the current style. Tools that scan imports can produce a report that lists every reference to collections.Iterable, so you do not need to rely only on manual inspection now.

Finally, write a short internal note once you close this issue in your own project. The next person who sees the same message in a different component will fix it faster with that note in mind. Over time your team learns to treat deprecation notes and removed aliases as normal parts of the upgrade cycle instead of surprises. Upgrades feel calmer for everyone.

Once you adopt collections.abc everywhere, the specific error attributeerror: module ‘collections’ has no attribute ‘iterable’ turns from a blocker into a quick signal that some older code slipped through your reviews.