notes: probe and note a parameter change once across function/method twins

[wufangyong973]

Fixes #5

When a parameter is removed from both a module function and the class method that mirrors it (hf_hub_download and HfApi.hf_hub_download in the Claude Opus 4.6 example), the run emitted one bullet per owner even though it is one concept.

The two small changes suggested in the issue:

• APIChange.concept_key now ignores the owner for param_* kinds, so selection probes the function/method pair once
• render_block merges bullets whose change has the same package, kind, name and parameter

Removed/moved objects keep their owner in the key — the module object and the method are still different concepts. The README example does not contain the affected huggingface-hub output, so no re-run is needed.

• 3 new tests in tests/test_units.py
• full suite 157 passed; ruff check/ruff format and mypy strict clean

[MohammadHijjawi97]

Thanks for picking up #5! The tests are clear and the idea is right, but the key is broader than the issue intends.

Dropping the owner for every parameter change also merges methods that only share a name and a parameter. Two examples from real diffs:

• anthropic: Messages.create(temperature=...) and Completions.create(temperature=...) are different APIs that would now be probed once, and render_block would then drop one of their notes.
• openai: many resources have create(stream=...) or list(limit=...); they would all collapse into one concept.

The case in #5 is narrower: a module-level function and a class method that mirrors it (hf_hub_download and HfApi.hf_hub_download). A way to keep exactly that:

• in selection.select (and wherever else concept_key is used to dedupe), first collect the (name, parameter) pairs of parameter changes on module-level functions (owner is None) in that package;
• give a method's parameter change the owner-free key only when its (name, parameter) is in that set;
• do the same check in render_block, instead of keying on (package, kind, name, parameter) alone.

A test with Messages.create(temperature) next to Completions.create(temperature) (both kept) plus the hf_hub_download twins (merged) would cover both sides.

Also, I just pushed 0.2.0 (2bd28fc), which changed apidiff.py, selection.py and notes.py a lot, so this will need a rebase onto main. Happy to do that part for you if you prefer; just say.

I've approved the CI run for this PR.

[MohammadHijjawi97]

Hi @wufangyong973, thanks for your patience here. A lot changed upstream since 0.1.0, so here's where this stands. 0.4.0 rebuilt the notes: diff_notes now makes one bullet per API (APIChange.api_key), with sync/async twins already merged (test_one_bullet_per_api_with_all_its_changes). The old render_block became render_legacy_block, which has to stay byte-identical to 0.3 for the run --compare baselines, and git would quietly apply your notes.py hunk there, so a plain rebase would change the baselines without touching the notes sync writes. concept_key also gained a branch for dependency switches (that's the conflict in apidiff.py). What #5 still needs is the narrower case from my review: a module-level function and the class method that mirrors it (hf_hub_download / HfApi.hf_hub_download) count as one, while Messages.create(temperature) and Completions.create(temperature) stay separate. To be fair, the issue text suggested the broad key you implemented, so that part is on me; I'll update #5. If you'd like to take it on, a fresh branch from main is probably easier than a rebase: the check belongs where selection.py dedupes by concept_key and where diff_notes groups by api_key, with a test covering both sides. If you'd rather not, just say so and I'll close this with thanks and pick it up.

[MohammadHijjawi97]

Hi @wufangyong973, just checking in on this one too. Are you still planning to rework it for the narrower case (a module-level function and the class method that mirrors it) on top of the 0.4 notes code?

If you're busy, that's completely fine: I can finish it on top of your commits and keep you as co-author. Just let me know which you prefer. If I don't hear back by October 11, I'll go ahead and do that.