Fix: fix: handle None module in module_available() to avoid TypeError

The Bug

Repo: pydata/xarray Issue: #11344 Status: PR-submitted PR: https://github.com/pydata/xarray/pull/11448

Description: fix: handle None module in module_available() to avoid TypeError

Fix scope: 5 lines changed in xarray/namedarray/utils.py

Root Cause

The edge case in T = TypeVar("T") at xarray/namedarray/utils.py causes incorrect behavior when a specific input condition is met. In Python, this pattern is easy to miss because standard test suites rarely cover every boundary condition.

The fix is a focused change — it addresses exactly the failing condition without refactoring surrounding code. This minimizes the risk of introducing new bugs.

Impact: The bug affects users who hit the specific edge case. For xarray, this means 5 lines fixes a scenario that could cause incorrect output, crashes, or silent data corruption depending on the code path.

The Fix

This is a focused fix — every line is deliberate and scoped to exactly the problem.

@@ -37,15 +37,15 @@ T = TypeVar("T")
 
 
 @lru_cache
-def module_available(module: str, minversion: str | None = None) -> bool:
+def module_available(module: str | None, minversion: str | None = None) -> bool:
     """Checks whether a module is installed without importing it.
 
     Use this for a lightweight check and lazy imports.
 
     Parameters
     ----------
-    module : str
-        Name of the module.
+    module : str or None
+        Name of the module. If None, returns False.
     minversion : str, optional
         Minimum version of the module
 
@@ -54,6 +54,8 @@ def module_available(module: str, minversion: str | None = None) -> bool:
     available : bool
         Whether the module is installed.
     """
+    if module is None:
+        return False
     if importlib.util.find_spec(module) is None:
         return False

Pattern & Takeaways

Pattern: Edge case in T = TypeVar("T") — the Python code path was not tested with the specific input that triggers the failure. The focused fix demonstrates that the most reliable approach is to change the minimum necessary code.

Key insight: The most predictable bugs are edge cases at input boundaries. Every function that accepts parameters has boundary conditions that example-based tests may miss. Code review should focus on: (1) What happens with empty/null input? (2) What happens at iteration boundaries? (3) What happens with unexpected types?

Transfer Potential

Varies — edge case fixes are repo-specific in detail but universal in pattern. The minimal-change principle and boundary-condition thinking transfer to any codebase. Reading this post helps recognize similar patterns in your own projects.

---

Auto-generated from PR #11344. View all patches on GitHub.