Should proxy objects lie about their class name?

[John J. Lee]

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?

One very real advantage that I can see is avoiding breaking existing
doctests.

Thanks in advance for your views


John

 

[John J. Lee]

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>


John

 

[Diez B. Roggisch]

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.

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.

Diez

 

[Carl Banks]

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?

One very real advantage that I can see is avoiding breaking existing
doctests.

Thanks in advance for your views

Python 3.0 has a proposal, accepted I believe, to allow classes to
control the behavior of issubclass and ininstance, so there appears to
be tacit support from the language for mimicking the proxied classes
in such ways.

I guess for me it would be a judgment call on based how tight I wanted
the proxy class to be--is it being the class, or is it just standing
in?


Carl Banks

 

[Fuzzyman]

Python 3.0 has a proposal, accepted I believe, to allow classes to
control the behavior of issubclass and ininstance, so there appears to
be tacit support from the language for mimicking the proxied classes
in such ways.

I guess for me it would be a judgment call on based how tight I wanted
the proxy class to be--is it being the class, or is it just standing
in?

In Python 2 you can already lie to 'isinstance' and 'issubclass' by
catching calls to the '__class__' and '__bases__' attribute. I'm not
sure yet whether this is a good thing however.

I have a proxy class I want to extend and am facing similar questions.

Michael
http://www.manning.com/foord

 

[Steven Bethard]

In Python 2 you can already lie to 'isinstance' and 'issubclass' by
catching calls to the '__class__' and '__bases__' attribute. I'm not
sure yet whether this is a good thing however.

The Python 3 machinery allows *other* classes to lie about whether or
not your object is an instance or subclass of them, without requiring
them to set your __class__ or __bases__. So, for example, you can
create a class ``Integer`` and make ``issubclass(int, Integer)`` true.
For more information see:

http://www.python.org/dev/peps/pep-3119/

STeVe

 

[Robin Becker]

Steven Bethard wrote:
........

The Python 3 machinery allows *other* classes to lie about whether or
not your object is an instance or subclass of them, without requiring
them to set your __class__ or __bases__. So, for example, you can
create a class ``Integer`` and make ``issubclass(int, Integer)`` true.
For more information see:

http://www.python.org/dev/peps/pep-3119/

STeVe

That will allow me to magically create instances which claim to be instances of
working_class even though they're actually instances of reactionary_class thus
turning all my modules into instances of class_war

 

[John J. Lee]

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