Re: Inheritance from builtin list and override of methods.

Discussion in 'Python' started by Michalis Giannakidis, Nov 27, 2006.

  1. On Monday 27 November 2006 11:50, Fredrik Lundh wrote:

    > "obj[index] = value" maps to "obj.__setitem__(index, value)". reading
    > the documentation might help; start here:
    >
    > http://docs.python.org/ref/specialnames.html


    In this documentation page it also says:
    --snip---
    then x is equivalent3.2 to x.__getitem__(i).
    --snip--
    This, and other statements, are only roughly true for instances of new-style
    classes.
    --snip--

    So which statements are actually true for new style classes?

    Is l[0]=1 completely different from l.append(1) or maybe insert?

    And is there a mechanism in Python that will allow me to override the
    operators of a class, for all its occurrences, even the ones implemented on C
    built-in objects?


    --
    Michalis Giannakidis
     
    Michalis Giannakidis, Nov 27, 2006
    #1
    1. Advertising

  2. Michalis Giannakidis

    Duncan Booth Guest

    Michalis Giannakidis <> wrote:

    > On Monday 27 November 2006 11:50, Fredrik Lundh wrote:
    >
    >> "obj[index] = value" maps to "obj.__setitem__(index, value)".
    >> reading the documentation might help; start here:
    >>
    >> http://docs.python.org/ref/specialnames.html

    >
    > In this documentation page it also says:
    > --snip---
    > then x is equivalent3.2 to x.__getitem__(i).
    > --snip--
    > This, and other statements, are only roughly true for instances of
    > new-style classes.
    > --snip--
    >
    > So which statements are actually true for new style classes?


    I think it means that the statements are true in general, but there may be
    specific corner cases which break them. Usually you can assume that the
    rough description will be good enough.

    >
    > Is l[0]=1 completely different from l.append(1) or maybe insert?


    Yes. It neither appends nor inserts.

    > And is there a mechanism in Python that will allow me to override the
    > operators of a class, for all its occurrences, even the ones
    > implemented on C built-in objects?


    No.
     
    Duncan Booth, Nov 27, 2006
    #2
    1. Advertising

  3. Duncan Booth wrote:

    >> And is there a mechanism in Python that will allow me to override
    >> the operators of a class, for all its occurrences, even the ones
    >> implemented on C built-in objects?

    >
    > No.


    For what it's worth, which is undoubtedly nothing, this is
    something that I think needs to change. All this talk about new-style
    classes and class-type unification is empty words if you can't override
    anything on any type without having to know whether it's written in C or
    Python.

    --
    --OKB (not okblacke)
    Brendan Barnwell
    "Do not follow where the path may lead. Go, instead, where there is
    no path, and leave a trail."
    --author unknown
     
    OKB (not okblacke), Nov 27, 2006
    #3
  4. On Mon, 2006-11-27 at 19:14 +0000, OKB (not okblacke) wrote:
    > Duncan Booth wrote:
    >
    > >> And is there a mechanism in Python that will allow me to override
    > >> the operators of a class, for all its occurrences, even the ones
    > >> implemented on C built-in objects?

    > >
    > > No.

    >
    > For what it's worth, which is undoubtedly nothing,


    Correct.

    > this is
    > something that I think needs to change. All this talk about new-style
    > classes and class-type unification is empty words if you can't override
    > anything on any type without having to know whether it's written in C or
    > Python.


    Duncan's "No" response was not referring to overriding in general, it
    was referring to the OP's original question which amounted to "Can I
    affect the behavior of method Z by overriding methods X and Y".

    The inability to influence a method by overriding completely different
    methods has nothing to do with whether that method is implemented in C
    or Python; it has to with whether the method in question calls the
    overridden methods, and in general it won't.

    You can change the behavior of a list's sort method by overriding sort.
    You can't change the behavior of sort by overriding __getitem__ and
    __setitem__, because sort does not call __getitem__ or __setitem__.

    Hope this helps,

    Carsten.
     
    Carsten Haese, Nov 27, 2006
    #4
  5. Carsten Haese wrote:

    > You can change the behavior of a list's sort method by overriding
    > sort. You can't change the behavior of sort by overriding
    > __getitem__ and __setitem__, because sort does not call __getitem__
    > or __setitem__.


    Why doesn't it?

    --
    --OKB (not okblacke)
    Brendan Barnwell
    "Do not follow where the path may lead. Go, instead, where there is
    no path, and leave a trail."
    --author unknown
     
    OKB (not okblacke), Nov 28, 2006
    #5
  6. OKB (not okblacke) wrote:

    > Why doesn't it?


    because whoever wrote the class didn't do things that way, mostly for
    efficiency reasons. there's nothing in Python that keeps you from using
    template methods if you want, but that's a costly approach, so it's not
    very common.

    I suggest reading up on OO design patterns.

    </F>
     
    Fredrik Lundh, Nov 28, 2006
    #6
  7. On Tuesday 28 November 2006 06:12, OKB (not okblacke) wrote:
    > Carsten Haese wrote:
    > > You can change the behavior of a list's sort method by overriding
    > > sort. You can't change the behavior of sort by overriding
    > > __getitem__ and __setitem__, because sort does not call __getitem__
    > > or __setitem__.

    >
    > Why doesn't it?


    I also expected that it did!

    I perfectly understand that this adds significant penalty to the execution of
    code. But in the way things are, I have to know ( or guess ?) how its
    function has been implemented. And I cannot handle all cases the same.

    If I provided my sort method for my class in Python, wouldn't this call my
    __getitem__ and __setitem__ methods (considering l = j assignment do)? Can
    this be considered an in consitency?

    --
    Michalis Giannakidis
     
    Michalis Giannakidis, Nov 28, 2006
    #7
  8. Michalis Giannakidis wrote:

    > I perfectly understand that this adds significant penalty to the execution of
    > code. But in the way things are, I have to know ( or guess ?) how its
    > function has been implemented.


    and that's different from how object orientation usually works in
    exactly what way?

    </F>
     
    Fredrik Lundh, Nov 28, 2006
    #8
  9. Michalis Giannakidis

    Carl Banks Guest

    OKB (not okblacke) wrote:
    > Carsten Haese wrote:
    >
    > > You can change the behavior of a list's sort method by overriding
    > > sort. You can't change the behavior of sort by overriding
    > > __getitem__ and __setitem__, because sort does not call __getitem__
    > > or __setitem__.

    >
    > Why doesn't it?


    Because the concerns of thousands of legitimate programmers who want
    good performance out of their sorts outweigh the concerns of the one or
    two hax0r d00ds who think it would be cool to hook into sort internals.


    live-long-and-prosper-ly yr's,


    Carl Banks
     
    Carl Banks, Nov 28, 2006
    #9
  10. Carl Banks wrote:

    > Because the concerns of thousands of legitimate programmers who want
    > good performance out of their sorts outweigh the concerns of the one or
    > two hax0r d00ds who think it would be cool to hook into sort internals.


    .... and haven't yet realized that using sorted() and converting back
    from the resulting list will outperform *any* solution they can come
    up with themselves.

    </F>
     
    Fredrik Lundh, Nov 28, 2006
    #10
    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. Replies:
    0
    Views:
    325
  2. Michalis Giannakidis
    Replies:
    0
    Views:
    279
    Michalis Giannakidis
    Nov 26, 2006
  3. DG
    Replies:
    3
    Views:
    337
    Terry Reedy
    Jul 22, 2009
  4. bdb112
    Replies:
    2
    Views:
    301
    Chris Torek
    Jul 2, 2011
  5. Ramza Brown
    Replies:
    1
    Views:
    118
Loading...

Share This Page