By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,399 Members | 886 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,399 IT Pros & Developers. It's quick & easy.

Should proxy objects lie about their class name?

P: n/a
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
Nov 20 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
jj*@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>
John
Nov 26 '07 #2

P: n/a
John J. Lee schrieb:
jj*@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.

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
Nov 26 '07 #3

P: n/a
On Nov 20, 3:50 pm, j...@pobox.com (John J. Lee) wrote:
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
Nov 27 '07 #4

P: n/a
On Nov 26, 11:56 pm, Carl Banks <pavlovevide...@gmail.comwrote:
On Nov 20, 3:50 pm, j...@pobox.com (John J. Lee) wrote:
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?

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
>
Carl Banks
Nov 27 '07 #5

P: n/a
Fuzzyman wrote:
On Nov 26, 11:56 pm, Carl Banks <pavlovevide...@gmail.comwrote:
>On Nov 20, 3:50 pm, j...@pobox.com (John J. Lee) wrote:
>>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.

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.

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
Nov 27 '07 #6

P: n/a
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 :)
--
Robin Becker

Nov 27 '07 #7

P: n/a
"Diez B. Roggisch" <de***@nospam.web.dewrites:
John J. Lee schrieb:
>jj*@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
Nov 27 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.