codehound 1.3.0__tar.gz → 1.4.1__tar.gz

{codehound-1.3.0 → codehound-1.4.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: codehound
-Version: 1.3.0
+Version: 1.4.1
 Summary: An AST-based static analyzer that hunts real correctness and async-safety bugs in Python code.
 Project-URL: Homepage, https://github.com/kratos0718/codehound
 Project-URL: Issues, https://github.com/kratos0718/codehound/issues
@@ -24,7 +24,7 @@ Description-Content-Type: text/markdown
 
 <h1 align="center">codehound</h1>
 
-**An AST-based static analyzer that hunts *real* bugs in large Python codebases — seven of the ten rules are backed by a bug that was actually found and merged into a major open-source AI framework; the other three are hardening rules verified against real false positives instead.**
+**An AST-based static analyzer that hunts *real* bugs in large Python codebases — twenty checks, seven backed by a bug that was actually found and merged into a major open-source AI framework, the rest hardening rules verified against real false positives across a ~20-framework validation corpus instead of just reasoned about.**
 
 [![CI](https://github.com/kratos0718/codehound/actions/workflows/ci.yml/badge.svg)](https://github.com/kratos0718/codehound/actions/workflows/ci.yml)
 [![PyPI](https://img.shields.io/pypi/v/codehound.svg)](https://pypi.org/project/codehound/)
@@ -34,7 +34,7 @@ Description-Content-Type: text/markdown
 
 Most linters flag style. `codehound` flags the *subtle correctness and async-safety bugs* that slip past code review and only bite in production — event-loop stalls, shared mutable state, leaked file descriptors, fire-and-forget tasks that get garbage-collected mid-run.
 
-Each of the six checks below isn't theoretical. **I wrote it after finding — and fixing, via a merged pull request — that exact bug in a real, popular framework** (agno 25k⭐, crewAI 30k⭐, mem0, huggingface_hub).
+Most of the checks below aren't theoretical. **I wrote them after finding — and fixing, via a merged pull request — that exact bug in a real, popular framework** (agno 25k⭐, crewAI 30k⭐, mem0, llama_index, accelerate).
 
 ---
 
@@ -71,7 +71,7 @@ I was contributing bug fixes to large AI frameworks and noticed the same handful
 pip install codehound
 ```
 
-Zero dependencies — it's ~750 lines on top of the standard-library `ast` module, so this installs instantly and runs fully offline, no API key or network call involved.
+Zero dependencies — it's ~2,200 lines on top of the standard-library `ast` module, so this installs instantly and runs fully offline, no API key or network call involved.
 
 <details>
 <summary>From a clone instead (for development)</summary>
@@ -117,7 +117,7 @@ codehound list
 ### GitHub Action
 
 ```yaml
-- uses: kratos0718/codehound@v1.2.0
+- uses: kratos0718/codehound@v1
   with:
     path: src
     # select: CH001,CH006        # optional, defaults to all checks
@@ -132,7 +132,7 @@ Uploads findings to the repo's **Security → Code Scanning** tab via SARIF, in
 ```yaml
 repos:
   - repo: https://github.com/kratos0718/codehound
-    rev: v1.2.0
+    rev: v1.4.1
     hooks:
       - id: codehound
 ```
@@ -153,15 +153,26 @@ repos:
 | **CH008** | `asyncio-run-in-running-loop` | `asyncio.run(...)` called from inside an `async def` — always raises `RuntimeError`, immediately, every time. | hardening rule — zero corpus hits (see below) |
 | **CH009** | `floating-thread` | A non-daemon `threading.Thread` that's `.start()`ed but never `.join()`ed — the thread analog of CH006. | hardening rule — see below |
 | **CH010** | `loop-closure-capture` | A `lambda` inside a `for` loop (or comprehension) that's *stored* (appended, assigned, returned) and captures the loop variable by reference — every stored instance ends up sharing the loop's **final** value. | **accelerate** (HuggingFace) — `MegatronEngine.get_module_config`'s `param_sync_func` list, PR #4273 |
+| **CH011** | `lru-cache-on-method` | `@lru_cache`/`@cache` decorating an instance method — the cache holds a strong reference to `self` forever, so every instance that ever calls the method leaks for the process lifetime. | **optuna** — `_FanovaTree`'s node-lookup methods leaked every tree built for a `get_param_importances()` call; **llama_index** — `VectaraIndex._get_corpus_key` leaked the index *and* broke its own `__del__`-based HTTP session cleanup |
+| **CH012** | `floating-process` | A non-daemon `multiprocessing.Process` that's `.start()`ed but never `.join()`ed — the process analog of CH009. | hardening rule |
+| **CH013** | `discarded-future` | `ThreadPoolExecutor`/`ProcessPoolExecutor.submit(...)` called as a bare statement — the returned `Future` (and any exception raised inside the submitted work) is silently discarded. | hardening rule — real hits in litellm, accelerate, langchain |
+| **CH014** | `unprotected-lock-acquire` | `lock.acquire()` outside a `with`, whose matching `.release()` isn't inside a `finally:` — an exception between acquire and release deadlocks every future caller of that lock. | hardening rule — real hits in vllm, accelerate, torchtune |
+| **CH015** | `async-property` | `@property`/`@cached_property` wrapping an `async def` — accessing the attribute hands back an un-awaited coroutine object, not the value. | hardening rule |
+| **CH016** | `unclosed-socket` | `socket.socket(...)` stored without a context manager or matching `.close()` — the socket analog of CH005; leaks the file descriptor. | hardening rule |
+| **CH017** | `collections-abc-import` | `from collections import Mapping` (or `Sequence`, `Iterable`, …) — the ABCs were removed from `collections` itself in Python 3.10; they live in `collections.abc`. | hardening rule |
+| **CH018** | `removed-asyncio-task-methods` | `asyncio.Task.current_task()` / `.all_tasks()` — both removed in Python 3.9; use `asyncio.current_task()` / `asyncio.all_tasks()`. | hardening rule |
+| **CH019** | `removed-getargspec` | `inspect.getargspec(...)` — removed in Python 3.11 after a decade-plus deprecation; use `inspect.signature(...)`. | hardening rule |
+| **CH020** | `bare-except` | A bare `except:` (or unused `except BaseException:`) — also catches `KeyboardInterrupt`/`SystemExit`, so Ctrl-C stops working and `sys.exit()` gets silently absorbed. | hardening rule — real hits in agno, llama_index, marimo, litellm |
 
 `codehound list` prints this from the source of truth.
 
-CH007-CH010 don't have found-and-merged bugs behind all of them the way
-CH001-CH006 do - three are hardening rules for well-known Python
+CH007-CH020 don't have found-and-merged bugs behind all of them the way
+CH001-CH006 do - most are hardening rules for well-known Python
 correctness gotchas rather than something this project personally
-tracked down first. CH010 is the exception: it found a genuine, serious
-bug on its own, in HuggingFace's `accelerate` - see below. Building all
-four surfaced real false positives, each one fixed before shipping:
+tracked down first. CH010 and CH011 are the exceptions: both found
+genuine bugs on their own, in HuggingFace's `accelerate`, optuna, and
+llama_index - see below. Building CH007-CH010 surfaced real false
+positives, each one fixed before shipping:
 
 - **CH007** (agno): a bare `self.foo()` call matched against an unrelated
   same-named `async def foo` on a *different* class (agno's own
@@ -199,14 +210,54 @@ it's very unlikely to survive basic testing; CH007 and CH009 both only
 match same-file names by design, and most real cases of either are
 plausibly cross-module.
 
-**One check we built and did not ship: CH011 `exception-chaining`**
-(`except X as e: raise Y(...)` with no `from e`, discarding the real
-traceback - overlaps flake8-bugbear B904). It worked exactly as designed,
-but at a scale that says more about how common the pattern is than about
-anything worth flagging: **1,911 hits across the same ~20-framework
-corpus**. Shipping a check that fires that often would make every scan
-result mostly CH011 noise, undermining the "a finding must be defensible"
-standard the rest of this tool holds itself to. Built, measured, and
+**The optuna and llama_index finds (CH011):** both are `@lru_cache(maxsize=
+None)` decorating an instance method - a strong reference to `self`
+retained forever. In optuna, `_FanovaTree`'s node-lookup methods leak
+every tree built for a `get_param_importances()` call (one per
+random-forest estimator). In llama_index, `VectaraIndex._get_corpus_key`
+leaks the index itself - and since `VectaraIndex.__del__` exists
+specifically to close the index's `requests.Session` on garbage
+collection, the leak silently disables that cleanup too, so an HTTP
+session leaks along with every index. Both fixed the same way: move the
+cache from a class-level decorator to a per-instance one built in
+`__init__`, so it's freed with the instance instead of outliving it. Both
+have a regression test verified to fail pre-fix and pass post-fix.
+PRs: [optuna/optuna#6859](https://github.com/optuna/optuna/pull/6859),
+[run-llama/llama_index#23089](https://github.com/run-llama/llama_index/pull/23089).
+
+**CH016 found and fixed its own false positive the day it shipped.** The
+first real-corpus scan of `unclosed-socket` turned up three hits in
+vllm's distributed process-group rendezvous code - all three sockets were
+actually handed off correctly (returned inside a tuple, collected into a
+list that's itself returned, passed as an argument into a function that
+takes ownership), just not in a shape CH005 (the check this one was
+modeled on) ever needed to recognize, since files aren't handed off this
+way nearly as often as rendezvous sockets are. Fixed by treating a name
+as escaped when it's returned as part of a tuple/list or passed as an
+argument to any call. A full corpus rescan afterward found zero remaining
+CH016 hits.
+
+**Two checks we built and did not ship.** `exception-chaining` (`except X
+as e: raise Y(...)` with no `from e`, discarding the real traceback -
+overlaps flake8-bugbear B904) worked exactly as designed, but at a scale
+that says more about how common the pattern is than about anything worth
+flagging: **1,911 hits across the same ~20-framework corpus**. Shipping a
+check that fires that often would make every scan result mostly noise,
+undermining the "a finding must be defensible" standard the rest of this
+tool holds itself to.
+
+`cancelled-error-swallowed` (`except asyncio.CancelledError: pass` -
+premise: silently swallowing task cancellation is a bug) went further
+than volume alone: the **first two real hits checked**, in two different
+frameworks, were both correct code, not bugs. agno's was `existing_task.
+cancel(); try: await existing_task; except CancelledError: pass` - the
+textbook-correct way to await a task's own cancellation. letta's was an
+explicit, logged recovery path (`except (CancelledError, ...) as e: logger
+.info(...); <continue processing>`) with a comment literally saying it was
+overriding the cancellation on purpose. Unlike the exception-chaining
+volume problem, this one meant the check's core premise was false in a
+large fraction of real occurrences - so it was deleted outright rather
+than kept at a lower confidence tier. Both are: built, measured, and
 deliberately left out - a real decision, not an oversight.
 
 ---
@@ -231,12 +282,22 @@ codehound/
     ├── unawaited_coroutine.py (CH007)
     ├── asyncio_run_in_loop.py (CH008)
     ├── floating_thread.py     (CH009)
-    └── loop_closure_capture.py (CH010)
+    ├── loop_closure_capture.py (CH010)
+    ├── lru_cache_on_method.py  (CH011)
+    ├── floating_process.py     (CH012)
+    ├── discarded_future.py     (CH013)
+    ├── unprotected_lock.py     (CH014)
+    ├── async_property.py       (CH015)
+    ├── unclosed_socket.py      (CH016)
+    ├── collections_abc_import.py (CH017)
+    ├── removed_asyncio_task_methods.py (CH018)
+    ├── removed_getargspec.py   (CH019)
+    └── bare_except.py          (CH020)
 ```
 
 Each check receives a parsed `ast` tree plus the precomputed parent map and returns `Finding`s. Adding a rule is one file + one registry line + a test. See [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) for a full walkthrough of the engine, the parent map, and the design decisions.
 
-**False-positive discipline is a feature.** CH005 won't flag a handle that's `return`ed (the caller owns it) or explicitly `.close()`d. CH006 won't flag `TaskGroup.create_task` (the group holds the reference). CH001 only fires when the *enclosing* function is `async`. CH007 scopes `self.foo()` matches to async methods on the *same* class as the call site, and bare `foo()` matches to module-level async functions that aren't shadowed by a same-named parameter. CH009 doesn't flag a thread handed off as *any* object's attribute, not just `self`. CH010 only fires when a lambda is directly stored (appended, assigned, returned), not merely passed as a callback argument that gets consumed on the spot. All four of those guards exist because of real false positives caught while building the checks (see above). The test suite asserts both "bad code is flagged" and "correct code is not."
+**False-positive discipline is a feature.** CH005 won't flag a handle that's `return`ed (the caller owns it) or explicitly `.close()`d. CH006 won't flag `TaskGroup.create_task` (the group holds the reference). CH001 only fires when the *enclosing* function is `async`. CH007 scopes `self.foo()` matches to async methods on the *same* class as the call site, and bare `foo()` matches to module-level async functions that aren't shadowed by a same-named parameter. CH009 doesn't flag a thread handed off as *any* object's attribute, not just `self`. CH010 only fires when a lambda is directly stored (appended, assigned, returned), not merely passed as a callback argument that gets consumed on the spot. CH016 doesn't flag a socket returned as part of a tuple/list, or passed as an argument to any call (as opposed to being the receiver of a call on itself) — real patterns found in vllm's rendezvous code. CH020 won't flag a `BaseException` handler whose bound name is actually referenced, or whose body re-raises anywhere in its own scope (not counting a nested try/except's own handler) — both real patterns found in agno. All of those guards exist because of real false positives caught while building the checks (see above and [`docs/FINDINGS.md`](docs/FINDINGS.md)). The test suite asserts both "bad code is flagged" and "correct code is not."
 
 ---
 
@@ -263,6 +324,9 @@ Every check has paired tests: the buggy pattern *is* flagged, and the idiomatic
 - [x] SARIF output — `--format sarif`
 - [x] Colored terminal output (auto-disabled for non-TTY / `NO_COLOR`)
 - [x] Multi-path `scan` invocation (what the pre-commit hook needs)
+- [x] 20 checks — memory leaks (`lru_cache` on methods), floating processes,
+      discarded futures, unprotected locks, async properties, unclosed
+      sockets, removed-in-3.9/3.10/3.11 stdlib APIs, bare `except:` — CH011-CH020
 - [ ] Cross-module resolution for CH007/CH009 (currently same-file only)
 - [ ] Sync HTTP clients constructed inside async request handlers
 - [ ] `--fix` for the mechanical rules (CH002, CH003, CH004)

{codehound-1.3.0 → codehound-1.4.1}/README.md

@@ -4,7 +4,7 @@
 
 <h1 align="center">codehound</h1>
 
-**An AST-based static analyzer that hunts *real* bugs in large Python codebases — seven of the ten rules are backed by a bug that was actually found and merged into a major open-source AI framework; the other three are hardening rules verified against real false positives instead.**
+**An AST-based static analyzer that hunts *real* bugs in large Python codebases — twenty checks, seven backed by a bug that was actually found and merged into a major open-source AI framework, the rest hardening rules verified against real false positives across a ~20-framework validation corpus instead of just reasoned about.**
 
 [![CI](https://github.com/kratos0718/codehound/actions/workflows/ci.yml/badge.svg)](https://github.com/kratos0718/codehound/actions/workflows/ci.yml)
 [![PyPI](https://img.shields.io/pypi/v/codehound.svg)](https://pypi.org/project/codehound/)
@@ -14,7 +14,7 @@
 
 Most linters flag style. `codehound` flags the *subtle correctness and async-safety bugs* that slip past code review and only bite in production — event-loop stalls, shared mutable state, leaked file descriptors, fire-and-forget tasks that get garbage-collected mid-run.
 
-Each of the six checks below isn't theoretical. **I wrote it after finding — and fixing, via a merged pull request — that exact bug in a real, popular framework** (agno 25k⭐, crewAI 30k⭐, mem0, huggingface_hub).
+Most of the checks below aren't theoretical. **I wrote them after finding — and fixing, via a merged pull request — that exact bug in a real, popular framework** (agno 25k⭐, crewAI 30k⭐, mem0, llama_index, accelerate).
 
 ---
 
@@ -51,7 +51,7 @@ I was contributing bug fixes to large AI frameworks and noticed the same handful
 pip install codehound
 ```
 
-Zero dependencies — it's ~750 lines on top of the standard-library `ast` module, so this installs instantly and runs fully offline, no API key or network call involved.
+Zero dependencies — it's ~2,200 lines on top of the standard-library `ast` module, so this installs instantly and runs fully offline, no API key or network call involved.
 
 <details>
 <summary>From a clone instead (for development)</summary>
@@ -97,7 +97,7 @@ codehound list
 ### GitHub Action
 
 ```yaml
-- uses: kratos0718/codehound@v1.2.0
+- uses: kratos0718/codehound@v1
   with:
     path: src
     # select: CH001,CH006        # optional, defaults to all checks
@@ -112,7 +112,7 @@ Uploads findings to the repo's **Security → Code Scanning** tab via SARIF, in
 ```yaml
 repos:
   - repo: https://github.com/kratos0718/codehound
-    rev: v1.2.0
+    rev: v1.4.1
     hooks:
       - id: codehound
 ```
@@ -133,15 +133,26 @@ repos:
 | **CH008** | `asyncio-run-in-running-loop` | `asyncio.run(...)` called from inside an `async def` — always raises `RuntimeError`, immediately, every time. | hardening rule — zero corpus hits (see below) |
 | **CH009** | `floating-thread` | A non-daemon `threading.Thread` that's `.start()`ed but never `.join()`ed — the thread analog of CH006. | hardening rule — see below |
 | **CH010** | `loop-closure-capture` | A `lambda` inside a `for` loop (or comprehension) that's *stored* (appended, assigned, returned) and captures the loop variable by reference — every stored instance ends up sharing the loop's **final** value. | **accelerate** (HuggingFace) — `MegatronEngine.get_module_config`'s `param_sync_func` list, PR #4273 |
+| **CH011** | `lru-cache-on-method` | `@lru_cache`/`@cache` decorating an instance method — the cache holds a strong reference to `self` forever, so every instance that ever calls the method leaks for the process lifetime. | **optuna** — `_FanovaTree`'s node-lookup methods leaked every tree built for a `get_param_importances()` call; **llama_index** — `VectaraIndex._get_corpus_key` leaked the index *and* broke its own `__del__`-based HTTP session cleanup |
+| **CH012** | `floating-process` | A non-daemon `multiprocessing.Process` that's `.start()`ed but never `.join()`ed — the process analog of CH009. | hardening rule |
+| **CH013** | `discarded-future` | `ThreadPoolExecutor`/`ProcessPoolExecutor.submit(...)` called as a bare statement — the returned `Future` (and any exception raised inside the submitted work) is silently discarded. | hardening rule — real hits in litellm, accelerate, langchain |
+| **CH014** | `unprotected-lock-acquire` | `lock.acquire()` outside a `with`, whose matching `.release()` isn't inside a `finally:` — an exception between acquire and release deadlocks every future caller of that lock. | hardening rule — real hits in vllm, accelerate, torchtune |
+| **CH015** | `async-property` | `@property`/`@cached_property` wrapping an `async def` — accessing the attribute hands back an un-awaited coroutine object, not the value. | hardening rule |
+| **CH016** | `unclosed-socket` | `socket.socket(...)` stored without a context manager or matching `.close()` — the socket analog of CH005; leaks the file descriptor. | hardening rule |
+| **CH017** | `collections-abc-import` | `from collections import Mapping` (or `Sequence`, `Iterable`, …) — the ABCs were removed from `collections` itself in Python 3.10; they live in `collections.abc`. | hardening rule |
+| **CH018** | `removed-asyncio-task-methods` | `asyncio.Task.current_task()` / `.all_tasks()` — both removed in Python 3.9; use `asyncio.current_task()` / `asyncio.all_tasks()`. | hardening rule |
+| **CH019** | `removed-getargspec` | `inspect.getargspec(...)` — removed in Python 3.11 after a decade-plus deprecation; use `inspect.signature(...)`. | hardening rule |
+| **CH020** | `bare-except` | A bare `except:` (or unused `except BaseException:`) — also catches `KeyboardInterrupt`/`SystemExit`, so Ctrl-C stops working and `sys.exit()` gets silently absorbed. | hardening rule — real hits in agno, llama_index, marimo, litellm |
 
 `codehound list` prints this from the source of truth.
 
-CH007-CH010 don't have found-and-merged bugs behind all of them the way
-CH001-CH006 do - three are hardening rules for well-known Python
+CH007-CH020 don't have found-and-merged bugs behind all of them the way
+CH001-CH006 do - most are hardening rules for well-known Python
 correctness gotchas rather than something this project personally
-tracked down first. CH010 is the exception: it found a genuine, serious
-bug on its own, in HuggingFace's `accelerate` - see below. Building all
-four surfaced real false positives, each one fixed before shipping:
+tracked down first. CH010 and CH011 are the exceptions: both found
+genuine bugs on their own, in HuggingFace's `accelerate`, optuna, and
+llama_index - see below. Building CH007-CH010 surfaced real false
+positives, each one fixed before shipping:
 
 - **CH007** (agno): a bare `self.foo()` call matched against an unrelated
   same-named `async def foo` on a *different* class (agno's own
@@ -179,14 +190,54 @@ it's very unlikely to survive basic testing; CH007 and CH009 both only
 match same-file names by design, and most real cases of either are
 plausibly cross-module.
 
-**One check we built and did not ship: CH011 `exception-chaining`**
-(`except X as e: raise Y(...)` with no `from e`, discarding the real
-traceback - overlaps flake8-bugbear B904). It worked exactly as designed,
-but at a scale that says more about how common the pattern is than about
-anything worth flagging: **1,911 hits across the same ~20-framework
-corpus**. Shipping a check that fires that often would make every scan
-result mostly CH011 noise, undermining the "a finding must be defensible"
-standard the rest of this tool holds itself to. Built, measured, and
+**The optuna and llama_index finds (CH011):** both are `@lru_cache(maxsize=
+None)` decorating an instance method - a strong reference to `self`
+retained forever. In optuna, `_FanovaTree`'s node-lookup methods leak
+every tree built for a `get_param_importances()` call (one per
+random-forest estimator). In llama_index, `VectaraIndex._get_corpus_key`
+leaks the index itself - and since `VectaraIndex.__del__` exists
+specifically to close the index's `requests.Session` on garbage
+collection, the leak silently disables that cleanup too, so an HTTP
+session leaks along with every index. Both fixed the same way: move the
+cache from a class-level decorator to a per-instance one built in
+`__init__`, so it's freed with the instance instead of outliving it. Both
+have a regression test verified to fail pre-fix and pass post-fix.
+PRs: [optuna/optuna#6859](https://github.com/optuna/optuna/pull/6859),
+[run-llama/llama_index#23089](https://github.com/run-llama/llama_index/pull/23089).
+
+**CH016 found and fixed its own false positive the day it shipped.** The
+first real-corpus scan of `unclosed-socket` turned up three hits in
+vllm's distributed process-group rendezvous code - all three sockets were
+actually handed off correctly (returned inside a tuple, collected into a
+list that's itself returned, passed as an argument into a function that
+takes ownership), just not in a shape CH005 (the check this one was
+modeled on) ever needed to recognize, since files aren't handed off this
+way nearly as often as rendezvous sockets are. Fixed by treating a name
+as escaped when it's returned as part of a tuple/list or passed as an
+argument to any call. A full corpus rescan afterward found zero remaining
+CH016 hits.
+
+**Two checks we built and did not ship.** `exception-chaining` (`except X
+as e: raise Y(...)` with no `from e`, discarding the real traceback -
+overlaps flake8-bugbear B904) worked exactly as designed, but at a scale
+that says more about how common the pattern is than about anything worth
+flagging: **1,911 hits across the same ~20-framework corpus**. Shipping a
+check that fires that often would make every scan result mostly noise,
+undermining the "a finding must be defensible" standard the rest of this
+tool holds itself to.
+
+`cancelled-error-swallowed` (`except asyncio.CancelledError: pass` -
+premise: silently swallowing task cancellation is a bug) went further
+than volume alone: the **first two real hits checked**, in two different
+frameworks, were both correct code, not bugs. agno's was `existing_task.
+cancel(); try: await existing_task; except CancelledError: pass` - the
+textbook-correct way to await a task's own cancellation. letta's was an
+explicit, logged recovery path (`except (CancelledError, ...) as e: logger
+.info(...); <continue processing>`) with a comment literally saying it was
+overriding the cancellation on purpose. Unlike the exception-chaining
+volume problem, this one meant the check's core premise was false in a
+large fraction of real occurrences - so it was deleted outright rather
+than kept at a lower confidence tier. Both are: built, measured, and
 deliberately left out - a real decision, not an oversight.
 
 ---
@@ -211,12 +262,22 @@ codehound/
     ├── unawaited_coroutine.py (CH007)
     ├── asyncio_run_in_loop.py (CH008)
     ├── floating_thread.py     (CH009)
-    └── loop_closure_capture.py (CH010)
+    ├── loop_closure_capture.py (CH010)
+    ├── lru_cache_on_method.py  (CH011)
+    ├── floating_process.py     (CH012)
+    ├── discarded_future.py     (CH013)
+    ├── unprotected_lock.py     (CH014)
+    ├── async_property.py       (CH015)
+    ├── unclosed_socket.py      (CH016)
+    ├── collections_abc_import.py (CH017)
+    ├── removed_asyncio_task_methods.py (CH018)
+    ├── removed_getargspec.py   (CH019)
+    └── bare_except.py          (CH020)
 ```
 
 Each check receives a parsed `ast` tree plus the precomputed parent map and returns `Finding`s. Adding a rule is one file + one registry line + a test. See [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) for a full walkthrough of the engine, the parent map, and the design decisions.
 
-**False-positive discipline is a feature.** CH005 won't flag a handle that's `return`ed (the caller owns it) or explicitly `.close()`d. CH006 won't flag `TaskGroup.create_task` (the group holds the reference). CH001 only fires when the *enclosing* function is `async`. CH007 scopes `self.foo()` matches to async methods on the *same* class as the call site, and bare `foo()` matches to module-level async functions that aren't shadowed by a same-named parameter. CH009 doesn't flag a thread handed off as *any* object's attribute, not just `self`. CH010 only fires when a lambda is directly stored (appended, assigned, returned), not merely passed as a callback argument that gets consumed on the spot. All four of those guards exist because of real false positives caught while building the checks (see above). The test suite asserts both "bad code is flagged" and "correct code is not."
+**False-positive discipline is a feature.** CH005 won't flag a handle that's `return`ed (the caller owns it) or explicitly `.close()`d. CH006 won't flag `TaskGroup.create_task` (the group holds the reference). CH001 only fires when the *enclosing* function is `async`. CH007 scopes `self.foo()` matches to async methods on the *same* class as the call site, and bare `foo()` matches to module-level async functions that aren't shadowed by a same-named parameter. CH009 doesn't flag a thread handed off as *any* object's attribute, not just `self`. CH010 only fires when a lambda is directly stored (appended, assigned, returned), not merely passed as a callback argument that gets consumed on the spot. CH016 doesn't flag a socket returned as part of a tuple/list, or passed as an argument to any call (as opposed to being the receiver of a call on itself) — real patterns found in vllm's rendezvous code. CH020 won't flag a `BaseException` handler whose bound name is actually referenced, or whose body re-raises anywhere in its own scope (not counting a nested try/except's own handler) — both real patterns found in agno. All of those guards exist because of real false positives caught while building the checks (see above and [`docs/FINDINGS.md`](docs/FINDINGS.md)). The test suite asserts both "bad code is flagged" and "correct code is not."
 
 ---
 
@@ -243,6 +304,9 @@ Every check has paired tests: the buggy pattern *is* flagged, and the idiomatic
 - [x] SARIF output — `--format sarif`
 - [x] Colored terminal output (auto-disabled for non-TTY / `NO_COLOR`)
 - [x] Multi-path `scan` invocation (what the pre-commit hook needs)
+- [x] 20 checks — memory leaks (`lru_cache` on methods), floating processes,
+      discarded futures, unprotected locks, async properties, unclosed
+      sockets, removed-in-3.9/3.10/3.11 stdlib APIs, bare `except:` — CH011-CH020
 - [ ] Cross-module resolution for CH007/CH009 (currently same-file only)
 - [ ] Sync HTTP clients constructed inside async request handlers
 - [ ] `--fix` for the mechanical rules (CH002, CH003, CH004)

{codehound-1.3.0 → codehound-1.4.1}/src/codehound/__init__.py

@@ -1,9 +1,10 @@
 """codehound - an AST-based static analyzer that hunts real bugs in Python code.
 
-Ten checks. Seven are each backed by a bug that was actually found and
+Twenty checks. Seven are each backed by a bug that was actually found and
 fixed in a popular open-source AI framework (agno, crewAI, mem0,
-llama_index, accelerate). The other three (CH007-CH009) are hardening
-rules verified against real false positives instead - see docs/FINDINGS.md.
+llama_index, accelerate). The rest (CH007-CH009, CH011-CH020) are
+hardening rules verified against real false positives across a
+~20-framework validation corpus instead - see docs/FINDINGS.md.
 """
 
 from __future__ import annotations
@@ -11,7 +12,7 @@ from __future__ import annotations
 from codehound.checks import ALL_CHECKS, get_checks
 from codehound.core import Check, Finding, scan_file, scan_path
 
-__version__ = "1.3.0"
+__version__ = "1.4.1"
 
 __all__ = [
     "ALL_CHECKS",

{codehound-1.3.0 → codehound-1.4.1}/src/codehound/checks/__init__.py

@@ -2,16 +2,26 @@
 
 from __future__ import annotations
 
+from codehound.checks.async_property import AsyncProperty
 from codehound.checks.asyncio_run_in_loop import AsyncioRunInRunningLoop
+from codehound.checks.bare_except import BareExcept
 from codehound.checks.blocking_async import BlockingCallInAsync
+from codehound.checks.collections_abc_import import CollectionsAbcImport
 from codehound.checks.datetime_utcnow import DeprecatedDatetimeUtcnow
+from codehound.checks.discarded_future import DiscardedFuture
+from codehound.checks.floating_process import FloatingProcess
 from codehound.checks.floating_task import FloatingTask
 from codehound.checks.floating_thread import FloatingThread
 from codehound.checks.get_event_loop import DeprecatedGetEventLoop
 from codehound.checks.loop_closure_capture import LoopClosureCapture
+from codehound.checks.lru_cache_on_method import LruCacheOnMethod
 from codehound.checks.mutable_defaults import MutableDefaultArgument
+from codehound.checks.removed_asyncio_task_methods import RemovedAsyncioTaskMethods
+from codehound.checks.removed_getargspec import RemovedGetargspec
 from codehound.checks.resource_leak import UnclosedFileHandle
 from codehound.checks.unawaited_coroutine import UnawaitedCoroutineCall
+from codehound.checks.unclosed_socket import UnclosedSocket
+from codehound.checks.unprotected_lock import UnprotectedLockAcquire
 from codehound.core import Check
 
 ALL_CHECKS: list[type[Check]] = [
@@ -25,6 +35,16 @@ ALL_CHECKS: list[type[Check]] = [
     AsyncioRunInRunningLoop,
     FloatingThread,
     LoopClosureCapture,
+    LruCacheOnMethod,
+    FloatingProcess,
+    DiscardedFuture,
+    UnprotectedLockAcquire,
+    AsyncProperty,
+    UnclosedSocket,
+    CollectionsAbcImport,
+    RemovedAsyncioTaskMethods,
+    RemovedGetargspec,
+    BareExcept,
 ]
 
 

codehound-1.4.1/src/codehound/checks/async_property.py

@@ -0,0 +1,54 @@
+"""CH015 - ``@property`` on an ``async def`` method returns an unawaited coroutine.
+
+Accessing a property never uses ``await`` - ``obj.thing`` is a plain
+attribute access, so Python has no way to know it should await anything
+even if the getter is a coroutine function. ``@property async def thing`` is
+syntactically legal, but every access silently hands back a coroutine
+object instead of the value, which is truthy, doesn't equal what you
+compare it to, and (if never awaited) is a hidden
+``RuntimeWarning: coroutine 'thing' was never awaited`` waiting to happen
+the first time someone actually uses the ``@property`` the way properties
+are meant to be used.
+"""
+
+from __future__ import annotations
+
+import ast
+
+from codehound.core import Check, Finding
+
+
+def _is_property_decorator(dec: ast.expr) -> bool:
+    if isinstance(dec, ast.Name):
+        return dec.id == "property"
+    if isinstance(dec, ast.Attribute):
+        return dec.attr in ("property", "cached_property")
+    return False
+
+
+class AsyncProperty(Check):
+    code = "CH015"
+    name = "async-property"
+    description = "@property wrapping an async def returns an unawaited coroutine, not the value."
+
+    def run(self, tree: ast.AST, parents: dict, path: str) -> list[Finding]:
+        findings: list[Finding] = []
+        for node in ast.walk(tree):
+            if not isinstance(node, ast.AsyncFunctionDef):
+                continue
+            if not any(_is_property_decorator(d) for d in node.decorator_list):
+                continue
+            findings.append(
+                Finding(
+                    path=path,
+                    line=node.lineno,
+                    col=node.col_offset,
+                    code=self.code,
+                    message=(
+                        f"`{node.name}` is an `async def` wrapped in `@property` - accessing it "
+                        f"never awaits anything, so every access returns an unawaited coroutine "
+                        f"object, not the value."
+                    ),
+                )
+            )
+        return findings

codehound-1.4.1/src/codehound/checks/bare_except.py

@@ -0,0 +1,88 @@
+"""CH020 - Bare ``except:`` (or unused ``except BaseException:``) catches everything.
+
+A bare `except:` (or the explicit `except BaseException:`) doesn't just
+catch the exception you meant to handle - it catches `KeyboardInterrupt`
+and `SystemExit` too, meaning Ctrl-C stops working and `sys.exit()` gets
+silently absorbed instead of actually exiting.
+
+Not flagged when the handler either **uses** the bound exception (a real,
+deliberate pattern found while building this: agno's background-thread
+runner, `except BaseException as e: thread_error.append(e)`, surfacing
+the exception to the consumer via a queue afterward - legitimate because
+it's a worker thread reporting failures back, not discarding them) or
+**re-raises anything** (another real pattern found the same way: agno's
+`except BaseException: <reset internal state>; raise` - properly
+propagates the original error to the caller after cleanup, so nothing is
+actually swallowed). A bare `except:` with neither has no way to inspect
+or propagate the exception at all, so it's flagged unconditionally.
+"""
+
+from __future__ import annotations
+
+import ast
+
+from codehound.core import Check, Finding
+
+
+def _name_is_referenced(scope: ast.AST, name: str) -> bool:
+    for node in ast.walk(scope):
+        if isinstance(node, ast.Name) and node.id == name and isinstance(node.ctx, ast.Load):
+            return True
+    return False
+
+
+def _has_raise_in_own_scope(handler: ast.ExceptHandler) -> bool:
+    """Any `raise` in the handler's own reachable body - not counting a
+    nested try/except's own handler, which is a different scope."""
+    found = False
+
+    def walk(node: ast.AST) -> None:
+        nonlocal found
+        if found:
+            return
+        for child in ast.iter_child_nodes(node):
+            if isinstance(child, ast.Raise):
+                found = True
+                return
+            if isinstance(child, ast.ExceptHandler):
+                continue
+            walk(child)
+
+    walk(handler)
+    return found
+
+
+class BareExcept(Check):
+    code = "CH020"
+    name = "bare-except"
+    description = "Bare `except:` (or unused `except BaseException:`) also catches KeyboardInterrupt/SystemExit."
+
+    def run(self, tree: ast.AST, parents: dict, path: str) -> list[Finding]:
+        findings: list[Finding] = []
+        for node in ast.walk(tree):
+            if not isinstance(node, ast.ExceptHandler):
+                continue
+            is_bare = node.type is None
+            is_base_exception = isinstance(node.type, ast.Name) and node.type.id == "BaseException"
+            if not (is_bare or is_base_exception):
+                continue
+            if _has_raise_in_own_scope(node):
+                continue
+            if is_base_exception and node.name is not None:
+                if any(_name_is_referenced(stmt, node.name) for stmt in node.body):
+                    continue
+            findings.append(
+                Finding(
+                    path=path,
+                    line=node.lineno,
+                    col=node.col_offset,
+                    code=self.code,
+                    message=(
+                        "bare `except:`" if is_bare else "`except BaseException:`"
+                    )
+                    + " also catches KeyboardInterrupt/SystemExit, and the exception isn't "
+                    "used anywhere in the handler; catch the specific exception(s) this "
+                    "handler is actually meant for.",
+                )
+            )
+        return findings