Inheriting frozenset gives bug if i overwrite __repr__ method

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • srinivasan srinivas

    Inheriting frozenset gives bug if i overwrite __repr__ method

    Hi,
    I am getting an error while executing the following snippet. If i comment out method __repr__ , it works fine.

    class fs(frozenset):
        def __new__(cls, *data):
            data = sorted(data)
            self = frozenset.__new __(cls, data)
            self.__data = data
            return self

        def __repr__(self):
            return "%s(%r)" % (self.__class__ .__name__, self.__data)

    a1 = fs(1,2,3)
    a2 = fs(3,4,5)
    print a1.difference(a 2)

    Error:
        return "%s(%r)" % (self.__class__ .__name__, self.__data)
    AttributeError: 'fs' object has no attribute '_fs__data'

    Please help me in fixing this.

    Thanks,
    Srini



    Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
  • Mark Dickinson

    #2
    Re: Inheriting frozenset gives bug if i overwrite __repr__ method

    On Nov 19, 12:39 pm, srinivasan srinivas <sri_anna...@ya hoo.co.in>
    wrote:
    a1 = fs(1,2,3)
    a2 = fs(3,4,5)
    print a1.difference(a 2)
    >
    Error:
        return "%s(%r)" % (self.__class__ .__name__, self.__data)
    AttributeError: 'fs' object has no attribute '_fs__data'
    I guess you need to implement the difference method in your
    subclass.

    It's a little odd that an operation on subclasses of frozenset returns
    an instance of the subclass, rather than simply a frozenset. Most
    other
    Python types don't work that way. Compare and contrast:

    Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
    [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
    Type "help", "copyright" , "credits" or "license" for more information.
    >>class myint(int): pass
    ....
    >>a = myint(3)
    >>b = myint(5)
    >>c = a+b
    >>c
    8
    >>type(c)
    <type 'int'>
    >>class fs(frozenset): pass
    ....
    >>a = fs([1, 2, 3])
    >>b = fs([3, 4, 5])
    >>c = a - b
    >>c
    fs([1, 2])
    >>type(c)
    <class '__main__.fs'>
    >>>
    Mark

    Comment

    • Gabriel Genellina

      #3
      Re: Inheriting frozenset gives bug if i overwrite __repr__ method

      En Wed, 19 Nov 2008 11:56:28 -0200, Mark Dickinson <dickinsm@gmail .com>
      escribió:
      On Nov 19, 12:39 pm, srinivasan srinivas <sri_anna...@ya hoo.co.in>
      wrote:
      >a1 = fs(1,2,3)
      >a2 = fs(3,4,5)
      >print a1.difference(a 2)
      >>
      >Error:
      >    return "%s(%r)" % (self.__class__ .__name__, self.__data)
      >AttributeError : 'fs' object has no attribute '_fs__data'
      >
      I guess you need to implement the difference method in your
      subclass.
      >
      It's a little odd that an operation on subclasses of frozenset returns
      an instance of the subclass, rather than simply a frozenset. Most
      other
      Python types don't work that way. Compare and contrast:
      Yep; looks like a bug in the set/frozenset implementation. Usually builtin
      types don't return subclasses because they don't know how the constructor
      should be called - it is indeed the case here, as the OP has changed
      frozenset.__new __ signature. Even if fs.__new__ were called its arguments
      would be wrong.
      The bug is not that the subclass constructor is skipped, but that
      a1.difference(a 2) returns a subclass instead of a frozenset instance.
      (set and frozenset are unrelated types but share a lot of their
      implementation by using generic algorithms, and it's the generic part the
      culprit here)

      --
      Gabriel Genellina

      Comment

      • Mark Dickinson

        #4
        Re: Inheriting frozenset gives bug if i overwrite __repr__ method

        On Nov 19, 4:23 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.a r>
        wrote:
        Yep; looks like a bug in the set/frozenset implementation.
        Thanks! I was about to report this to bugs.python.org , but it
        looks as though Raymond's been at the time machine again:



        It's fixed in 3.0; backporting the fix to 2.x was deemed too risky.

        Mark

        Comment

        Working...