Should proxy objects lie about their class name?

Discussion in 'Python' started by John J. Lee, Nov 20, 2007.

  1. John J. Lee

    John J. Lee Guest

    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, Nov 20, 2007
    #1
    1. Advertising

  2. John J. Lee

    John J. Lee Guest

    (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
    John J. Lee, Nov 26, 2007
    #2
    1. Advertising

  3. John J. Lee schrieb:
    > (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
    Diez B. Roggisch, Nov 26, 2007
    #3
  4. John J. Lee

    Carl Banks Guest

    On Nov 20, 3:50 pm, (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
    Carl Banks, Nov 26, 2007
    #4
  5. John J. Lee

    Fuzzyman Guest

    On Nov 26, 11:56 pm, Carl Banks <> wrote:
    > On Nov 20, 3:50 pm, (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
    Fuzzyman, Nov 27, 2007
    #5
  6. Fuzzyman wrote:
    > On Nov 26, 11:56 pm, Carl Banks <> wrote:
    >> On Nov 20, 3:50 pm, (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
    Steven Bethard, Nov 27, 2007
    #6
  7. John J. Lee

    Robin Becker Guest

    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
    Robin Becker, Nov 27, 2007
    #7
  8. John J. Lee

    John J. Lee Guest

    "Diez B. Roggisch" <> writes:

    > John J. Lee schrieb:
    >> (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
    John J. Lee, Nov 27, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ilias Lazaridis
    Replies:
    0
    Views:
    896
    Ilias Lazaridis
    Dec 12, 2004
  2. axter
    Replies:
    16
    Views:
    3,234
    Thomas G. Marshall
    Feb 27, 2005
  3. Jeff Epler
    Replies:
    10
    Views:
    654
    Anton Vredegoor
    Aug 20, 2003
  4. Replies:
    2
    Views:
    451
    Roderik
    Aug 3, 2008
  5. Replies:
    2
    Views:
    82
    Thomas 'PointedEars' Lahn
    Jul 29, 2008
Loading...

Share This Page