Having an 'x' getter and a 'get_x' method leads to an internal naming conflict

[ajwock]

Bug Description

In one of my pyo3 projects, I need to have both an 'x' attribute and a 'get_x' method with additional parameters for some more specialized calculations of the value. This naming is necessary for backwards compatibility.

However, this produces an internal compiler error due to naming conflict.

Below you can see that even using 'name = ...' doesn't fix the issue.

Steps to Reproduce

pyo3_naming_limitation working example

Working example, just cargo build. Here is the code contained immediately, for convenience:

#[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
    }

    #[getter]
    fn y(&self) -> u32 {
        self.y
    }

    #[pyo3(name = "get_y")]
    fn y_get(&self) -> u32 {
        self.y
    }

}

Backtrace

error[E0592]: duplicate definitions with name `__pymethod_get_x__`
  --> src/lib.rs:21:1
   |
21 | #[pymethods]
   | ^^^^^^^^^^^^
   | |
   | duplicate definitions for `__pymethod_get_x__`
   | other definition for `__pymethod_get_x__`
   |
   = note: this error originates in the attribute macro `pymethods` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0592]: duplicate definitions with name `__pymethod_get_y__`
  --> src/lib.rs:21:1
   |
21 | #[pymethods]
   | ^^^^^^^^^^^^
   | |
   | duplicate definitions for `__pymethod_get_y__`
   | other definition for `__pymethod_get_y__`
   |
   = note: this error originates in the attribute macro `pymethods` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0592`.
error: could not compile `pyo3_limitation` (lib) due to 2 previous errors

Your operating system and version

Debian GNU/Linux 13 (trixie)

Your Python version (python --version)

3.13.9

Your Rust version (rustc --version)

1.94.1

Your PyO3 version

0.27.0

How did you install python? Did you use a virtualenv?

This can be replicated without running python.

Additional Info

No response

[Harikeshav-R]

It looks like the root cause here is that #[pymethods] generates internal wrapper functions with names that can collide across different method types. Specifically:

• A #[getter] fn x() generates a wrapper named __pymethod_get_x__ (via format_ident!("__pymethod_get_{}__", spec.name))
• A regular method fn get_x() generates __pymethod_get_x__ (via format_ident!("__pymethod_{}__", spec.python_name))

The same applies to setters (__pymethod_set_{}__) and deleters (__pymethod_delete_{}__).

Simply renaming the prefix (e.g. getter_ instead of get_) just shifts the collision to a different method name. Any prefix-based scheme has this problem.

One approach that could help here: since the #[pymethods] macro has access to all methods in the impl block, it could collect all generated wrapper ident names during expansion, detect duplicates, and emit a clear compile error explaining the conflict, something like:

#[getter] fn x() and fn get_x() produce conflicting internal method definitions. Consider renaming the method or using #[pyo3(name = "...")] on the getter to avoid this conflict.

This wouldn't remove the limitation, but it would replace the current cryptic E0592: duplicate definitions with name '__pymethod_get_x__' with a meaningful diagnostic. Would this be a good direction, or is there a possibility for a fix that eliminates the collision entirely (e.g. encoding the method type into the wrapper name in a way that partitions the namespace)?

[ajwock]

If plain methods that are not a special method type (getter, setter, deleter, etc) had their own special prefix (e.g. __pymethod_standard_{}) this would prevent the issue without shifting the collision to a different name. It is this lack of a prefix for standard methods that allows part of the name to collide with the prefixes assigned internally to non-standard methods.

In this example we would have __pymethod_get_x__ and __pymethod_standard_get_x__. (standard is bikeshed ofc, basically anything would work)

[davidhewitt]

One approach that could help here: since the #[pymethods] macro has access to all methods in the impl block, it could collect all generated wrapper ident names during expansion, detect duplicates, and emit a clear compile error explaining the conflict, something like

The macro doesn't know all methods; with multiple-pymethods feature these may appear in separate impl blocks.

In this example we would have __pymethod_get_x__ and __pymethod_standard_get_x__. (standard is bikeshed ofc, basically anything would work)

In that example then users can no longer write fn standard_get_x.

But I think a variant of your proposal where we name getter methods with a different prefix like __getter_pymethod_x__ would make it impossible for these to collide.

[ajwock]

In that case, fn standard_get_x is represented by __pymethod_standard_standard_get_x__ internally. What wouldn't be possible would be introducing a different special class of method to the pyo3 generator that generates the __pymethod_standard prefix. The effect of what I'm suggesting would be like having an attribute with the way things work now called get_x. If you wrote a getter for get_x, it would internally generate __pymethod_get_get_x__.

For clarity, lets say you write all of these functions in the same class:

    // generates __pymethod_get_x__
    #[getter]
    fn x(&self) -> u32 {
        self.x
    }
     // generates __pymethod_standard_get_x__
    fn get_x(&self) -> u32 {
        self.x
    }

    // generates __pymethod_standard_standard_get_x__
    fn standard_get_x(&self) -> u32 {
        self.x
    }

What I'm saying is that there's no way to name setters and getters such that a setter's name would conflict with a getter's name. But because regular methods don't have their own qualifying prefix, you can name a regular method to conflict with a getter.