fix: avoid #[pymethods] name collisions between regular methods and #[getter]/#[setter]/#[deleter]

[mokashang]

Closes #5974.

Bug

The #[pymethods] macro generates an internal associated function for
every entry in the impl block. Up to now those names came from two
different conventions that overlap:

kind	wrapper name
#[getter] fn x	__pymethod_get_x__
#[setter] fn x	__pymethod_set_x__
#[deleter] fn x	__pymethod_delete_x__
regular method fn x	__pymethod_x__

So defining both a property and a same-named accessor method — #[getter] fn x + fn get_x — collides on __pymethod_get_x__ with error[E0592]: duplicate definitions. The same trap exists for set_X against #[setter] and delete_X against #[deleter]. It also survives #[pyo3(name = "get_y")] renames, because the regular-method wrapper is keyed off spec.python_name, not the Rust identifier:

#[pyclass]
pub struct Object { x: u32, y: u32 }

#[pymethods]
impl Object {
    #[getter] fn x(&self) -> u32 { self.x }
    fn get_x(&self) -> u32 { self.x }                        // collision

    #[getter] fn y(&self) -> u32 { self.y }
    #[pyo3(name = "get_y")] fn y_get(&self) -> u32 { self.y } // collision
}
// error[E0592]: duplicate definitions with name `__pymethod_get_x__`
// error[E0592]: duplicate definitions with name `__pymethod_get_y__`

This blocks a common Python pattern: shipping a cheap value property alongside a parameterised get_value(...) method for callers that need the underlying computation. The original report (#5974) is a real adaptation case where backwards-compatible naming required exactly this shape.

Fix

Switch the wrapper name for regular methods from __pymethod_{python_name}__ to __pymethod_method_{python_name}__ in impl_py_method_def. The method infix can no longer be a substring of get_, set_, or delete_, so the prefix space is now disjoint regardless of which Python name the user chooses. This matches the direction agreed in #5974 (comment) — pick a distinct prefix for "ordinary" methods — and method reads more naturally than standard while having the same effect.

The change is purely internal: these __pymethod_*__ symbols are private associated items consumed by other macro-generated code in the same expansion. No public API moves.

Scope

I deliberately kept this narrow:

• Only the regular-method site in pyo3-macros-backend/src/pymethod.rs is changed; the #[classattr] and gen_py_const sites also generate __pymethod_{name}__, but their collision space (uppercase-snake constants, class-level Python names) is much harder to hit in real code than get_X / set_X / delete_X. Happy to expand if reviewers prefer.
• __pymethod___new____, __pymethod___richcmp____, __pymethod_traverse__, __pymethod_constructor__, __pymethod_variant_cls_* etc. are unchanged — they don't share the property-prefix shape.

Tests

• Added property_and_regular_method_can_share_name_prefix in tests/test_getter_setter.rs. It exercises all three collision shapes — regular method (fn get_x), #[pyo3(name = "get_y")] fn y_get rename, and the setter variant fn set_z against #[setter] fn z — and verifies that each callable reaches the right Rust impl from Python (instance.x == 10 vs instance.get_x() == 11, etc.). Without the fix this test fails to compile with E0592.
• Updated tests/ui/invalid_pymethods_duplicates.rs (+ .stderr snapshot): the existing "two methods both renamed to func" duplicate-detection still trips, just on __pymethod_method_func__ now.
• cargo test -p pyo3 --tests is green across the test suite I can run locally on macOS (class basics, class attributes, getter/setter, methods, proto methods, multiple-pymethods feature, inheritance, declarative module, etc.). UI tests that fail on my machine all fail identically on main — they're rustc-version-sensitive snapshots and unrelated to this change.
• cargo fmt --check clean; cargo clippy --tests --features=macros clean.

[codspeed-hq]

Merging this PR will not alter performance

✅ 126 untouched benchmarks

---

_{Comparing mokashang:fix/pymethod-name-collision-with-property (1bbdc5f) with main (4c8407d)}

[ngoldbaum]

IMO this kind of comment isn't really helpful. The one in the test is sufficient.

[mokashang]

Agreed — dropped the comment in b07540f. The test docstring already covers it.

[mokashang]

Pushed 1bbdc5f to fix the CI failure on python3.14t-x64.

The renamed wrapper identifier broke tests/ui/invalid_pyclass_generic — the test's //~ ERROR annotation and .stderr snapshot still spelled the old __pymethod___class_getitem____ symbol. Updated both to __pymethod_method___class_getitem____ so trybuild matches.

Verified locally: cargo test --test test_compile_error ... invalid_pyclass_generic now passes (1 passed; 63 filtered out).