Type hint for specific __getattr__ use-case?

[omer54463]

I encountered a problem in one of my projects, where I wanted to forward member accesses to a member of the class.
Something like this:

class Container[T]:
    member: T

    def __init__(self, member: T) -> None:
        self.member = member

    def __getattr__(self, name: str) -> Any:
        return getattr(self.member, name)

class Class:
    def method(self) -> None:
        print("Hello, world!")

def main() -> None:
    container = Container(Class())
    container.method() # Prints "Hello, world!", but no hint suggest it exists at all.

if __name__ == "__main__":
    main()

I thought this is kind of niche, but the moment I described it to a friend he pulled up his own class which does this.
Is this a common use case? If so, I have 2 ideas.

First idea (typing based):
This requires no language changes, just a new typing thingy.

class Container[T](Relay[T]):
    member: T

    def __init__(self, member: T) -> None:
        self.member = member

    def __getattr__(self, name: str) -> Any:
        return getattr(self.member, name)

This Relay type would mean exactly what we want - an attribute lookup should be forwarded to T if it not found.

Second idea (python based):
This requires a new python feature, which is essentially my specific use-case as a feature.

class Container[T]:
    member: T

    def __init__(self, member: T) -> None:
        self.member = member

    def __deref__(self) -> T:
        return self.member

This is very similar to rust's Deref:

use std::ops::Deref;

struct Container<T> { member: T }

impl<T> Deref for Container<T> {
    type Target = T;
    fn deref(&self) -> &T { &self.member }
}

struct Struct { }

impl Struct {
    fn method(&self) { println!("Hello, world!") }
}

fn main() {
    let container = Container { member: Struct {} };
    container.method();
}

What do you think? I'm looking for feedback.

[Daverball]

A proxy type has been suggested a few times before, there's also this pre-existing issue: #802

[Daverball]

I think it's also worth noting that a proxy type is conceptually really close to an intersection, so maybe the need for an explicit proxy type will go away if/when intersections become a thing in the python type system.

In some ways all you're really asking for is that any operation that works on A should also work on B which is a proxy type for A, which you can also write as B & A. Although it is a little less ergonomic having to do the intersection manually, rather than baked into the class, although you could probably write a little factory function to do that step for you like def proxy(x: T) -> Proxy & T: .... Or you could probably use __new__ on the proxy class for that purpose as well i.e. def __new__(cls, x: T) -> Self & T: ...

[omer54463]

A proxy type has been suggested a few times before, there's also this pre-existing issue: #802

Most of those suggestions want the wrapping object's methods to be inaccessible.

Some don't, and suggest an intersection type, but that is not good enough.

If the wrapping class has a method with the same name as the wrapped class, but a different signature, I'd want the wrapped class's method to be the one called and hinted.

The wrapped class should strictly be a fallback.

I have a plugin which does this, but Pylance doesn't respect mypy plugins...

[Daverball]

B & A in an intersection generally has precedence, same as multiple inheritance, an intersection with incompatible signatures for any of the overlapping methods would and should probably raise an error, but if you ignore that error, I expect the first type's signature to receive precedence, so whether or not intersections are actually insufficient to model the behavior you want will depend on the semantics we end up with.