Argument Of Type “WindowsPath” Is Not Iterable | Fix It

Seeing the this WindowsPath TypeError message in a traceback can stop your script cold, especially if the same code behaved fine on Linux or macOS. This message comes from Python on Windows when code treats a pathlib.Path object as something you can loop over or search with the in operator.

This article walks through what the error means, the patterns that trigger it on Windows, and the changes that clear it for good. You will see short code examples for common cases, like checking file names, working with Django settings, or passing paths into libraries and tools.

What This WindowsPath Typeerror Actually Means

When Python says argument of type "WindowsPath" is not iterable, it is complaining about an expression that expects something you can iterate over, such as a string, list, tuple, or bytes object. A WindowsPath object represents a file system path on Windows. It behaves like a single value, not a sequence of smaller values.

On other platforms, plain Path objects sometimes behave a little differently, which adds to the confusion. Code that worked on another operating system might now fail on Windows when you run the same project. The core idea stays the same though: you tried to apply an operation that needs an iterable to a path object.

The message often appears around a membership test. Python reaches code such as if "pdf" in my_path: or a library calls something like "\\" in path behind the scenes. Since the path object is not iterable in that context on Windows, Python raises a TypeError with this text.

To see why this matters, think about how the in operator behaves on different values. With a list, item in my_list walks through each element. With a string, "ab" in "abc" walks through the characters. A path object does not expose that step on Windows, so Python refuses to run the test. Once you move the check onto path.name, path.stem, or str(path), the operator receives a real sequence.

Common Situations That Trigger The Error On Windows

Several coding patterns bring out this message. Once you can spot them, the fix becomes much easier. The list below shows problems that show up again and again in real projects.

• Membership tests on a Path object — Code checks a substring inside a path with if "name" in file_path: instead of using the file name or converting to a string.
• Configuration values stored as Path — A setting such as a database path or template directory is stored as a Path object, then a framework expects a plain string.
• Subprocess or C extension calls — A library loops over arguments passed to a native call and expects each one to be a string, not a path object.
• Accidental reuse of generators — Code uses Path.glob() and then loops through the results more than once while also using membership tests on the entries.

The table below links the kind of code to the typical fix you will use.

Many online threads about this TypeError show the same pattern. Someone uses Path to clean up path handling, then hits this message when code compares file names, when a database cannot open, or when a CUDA or PDF tool crashes.

Fixing The Argument Of Type “WindowsPath” Is Not Iterable Error In Python

This section shows practical code before and after the fix. You can adapt each pattern to your own project and clear the argument of type "WindowsPath" is not iterable message without guessing.

Fix 1: Check File Names, Not The Raw Path Object

Many scripts check whether a language code, extension, or keyword appears inside a file name. With Path objects you can still do that, but you should work with the name or stem property, not the entire path object.

from pathlib import Path

source_dir = Path("C:/data/texts")
files = source_dir.glob("*.txt")

languages = ["dutch", "english", "french"]

# Problem pattern
for language in languages:
    for file_path in files:
        if language in file_path:  # raises TypeError on Windows
            ...

Here Python checks membership on the WindowsPath instance directly. On Windows that fails. You instead want to check the file name or the stem.

from pathlib import Path

source_dir = Path("C:/data/texts")
files = source_dir.glob("*.txt")

languages = ["dutch", "english", "french"]

# Safer pattern
for language in languages:
    for file_path in source_dir.glob("*.txt"):
        if language in file_path.stem:
            text = file_path.read_text(encoding="utf-8")
            # process text here

Using file_path.stem gives you the file name without the extension. You could also use file_path.name to include the extension when searching.

Fix 2: Convert Path Objects To Strings Where Libraries Expect Text

Some libraries still expect plain strings for paths. They might call string methods on them, or run checks such as '/' in arg or ' ' in arg. When they meet a WindowsPath instance, the same membership test leads straight to the error.

• Wrap settings in str() — In Django settings, use 'NAME': str(BASE_DIR / 'db.sqlite3') so the framework receives a string path.
• Convert before subprocess calls — When you pass paths into subprocess.run, call str(path_obj) or path_obj.as_posix() in the argument list.
• Normalize paths at the boundary — When a helper function receives a path argument, convert it to Path inside the function and convert back to a string only when you call a lower level API that demands text.

from pathlib import Path
import subprocess

def run_tool(executable: Path, input_file: Path) -> None:
    cmd = [str(executable), str(input_file)]
    subprocess.run(cmd, check=True)

This pattern keeps most of your code on Path objects, yet libraries that need plain strings still receive the type they expect. The error message then disappears.

Fix 3: Watch Out For Generators And One-Time Iterators

The glob method returns an iterator over path objects. After you consume it once, you should not reuse the same iterator in another nested loop. That problem combines with the WindowsPath membership error in puzzling ways.

source_dir = Path("C:/data/texts")
files = source_dir.glob("*.txt")

for language in languages:
    for file_path in files:
        if language in file_path.stem:
            ...

Inside the second loop you may see the error, or nothing might run at all after the first language. A safer approach is to call glob fresh in each loop or convert the iterator to a list first.

• Recreate the iterator — Move source_dir.glob("*.txt") inside the outer loop.
• Materialize the list once — Use files = list(source_dir.glob("*.txt")) and loop over files as many times as needed.

files = list(source_dir.glob("*.txt"))

for language in languages:
    for file_path in files:
        if language in file_path.stem:
            ...

This change does not just remove the TypeError. It also makes the code clearer, since you treat file paths as a simple list of path objects instead of a one-time stream.

Fixes For Libraries, Frameworks, And Tools

Sometimes the traceback points inside a library such as a CUDA helper, a documentation builder, or a web framework. The last line might land in subprocess or a C extension, and the message still reads this WindowsPath TypeError. The root cause stays the same: a function checks membership on an argument that happens to be a path object.

You can still control the input to that library from your code. The fixes listed here describe the boundary between your project and the external package.

• Django database and media paths — Wrap expressions such as BASE_DIR / "db.sqlite3" and BASE_DIR / "media" in str() so Django receives plain strings in settings.
• Third party CUDA or PDF tools — When a helper takes a path parameter, read the docs and pass str(path_obj) instead of the raw Path on Windows.
• CLI wrappers — If you build a thin wrapper around a command line tool, convert each Path argument to a string just before calling the tool.

def pdf_to_text(pdf_path: Path, output_dir: Path) -> None:
    command = ["pdftotext", str(pdf_path), str(output_dir / "out.txt")]
    subprocess.run(command, check=True)

If you contribute to an open source project and see this issue inside that code, a small patch that calls str() on Windows can help other users avoid the same crash.

Step By Step Debugging Checklist

When the error pops up inside a long script, it can feel hard to track down the exact line that triggered it. A short checklist brings structure to the search and keeps time lost to a minimum.

1. Read the full traceback — Scroll to the last block of Python code from your project and note the file, line number, and function name.
2. Locate the iterable operation — Look on that line for an in test, a loop, or a function that expects a sequence or string.
3. Print the type of each variable — Insert print(type(value)) and run again to confirm which variable is a WindowsPath.
4. Convert or adjust the expression — Change the code so the iterable part is a list, string, or similar structure, not the raw path object.
5. Run a small, focused test — Reproduce the error with a tiny script that holds only the paths and expressions involved, then confirm the fix there.

This process turns a vague message into a specific line you can change. Once you know which path object caused trouble, you can choose whether to use its name, stem, parent directory, or full string form.

Good Habits To Avoid The WindowsPath Error Next Time

You can reduce the odds of seeing this WindowsPath TypeError again by setting a few simple habits in your projects. These habits center on consistent types and clear boundaries.

It also helps to agree on a set of patterns with your team. Treat Path objects as the default in new modules, and write down when a function should return a string path instead.

• Pick one path style per layer — Inside most of your code, stick to Path objects. Only convert back to strings in a thin wrapper that calls older libraries.
• Name variables clearly — Use names such as config_path, db_path, or pdf_file_path instead of a bare file variable.
• Add small unit tests — Write tests that run on Windows and confirm that functions accept and return the path types you expect.
• Review new code that touches paths — When you change how your project handles files, scan the diff for any in tests or loops that touch paths.

With those practices in place, the next time you refactor to use pathlib, the upgrade stays smooth and the argument of type "WindowsPath" is not iterable message stays out of your logs.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback