Should proxy objects lie about their class name?

[John J. Lee]

"Diez B. Roggisch" <deets at nospam.web.de> writes:

> John J. Lee schrieb:
>> jjl at pobox.com (John J. Lee) writes:
>>
>>> Not much to add to the subject line.  I mean something like this:
>>>
>>> ProxyClass.__name__ = ProxiedClass.__name__
>>>
>>>
>>> I've been told that this is common practice.  Is it?  Would this
>>> surprise you if you ran into it in a debugging session?
>>
>> Does nobody have an opinion on this?  Pull your socks up, c.l.py!
>>
>> <insert reference to argument sketch here>
>
> I've written quite a few proxies, but none of them did that. IMHO this
> is similar to using isinstance overeagerly: it works against the
> duck-typing principle to guard code by requiring certain base-classes,
> instead of just relying on protocol. The same applies here.

Sure.  The push here was the doctest issue.


> There might be of course cases where you have code lying around that
> does do some distinctions based on the class-name (I'm certainly I've
> seen such stuff once or tiwce, but always regarded it a WTF). Then
> doing as you do above might help in getting things work.

Right.

The actual case I'm talking about here involved an exception class
(dynamically created by subclassing at runtime, eugh) -- and a common
one at that -- so it's a pretty common thing in doctests and any
workaround on the doctest level would be very ugly (of course,
alternatives include working around it by wrapping the code that
raises the exception, or changing the doctest files to use the new
exception name).

What worries me is the potential for confusion.  Again, would it
confuse you (not just Diez, everybody)?


John