Re: __eq__() inconvenience when subclassing set

2009-11-02 Thread Jess Austin
On Nov 1, 1:13 am, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: Looks like in 3.1 this can be done with bytes+str and viceversa, even if   bytes and str don't have a common ancestor (other than object; basestring   doesn't exist in 3.x): p3 Base = bytes p3 Other = str p3 p3 class

Re: __eq__() inconvenience when subclassing set

2009-11-02 Thread Gabriel Genellina
En Mon, 02 Nov 2009 22:05:42 -0300, Jess Austin jess.aus...@gmail.com escribió: On Nov 1, 1:13 am, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: Looks like in 3.1 this can be done with bytes+str and viceversa, even if bytes and str don't have a common ancestor (other than object;

Re: __eq__() inconvenience when subclassing set

2009-11-01 Thread Gabriel Genellina
En Fri, 30 Oct 2009 17:55:27 -0300, Jess Austin jess.aus...@gmail.com escribió: On Oct 29, 10:41 pm, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: We know the last test fails because the == logic fails to recognize mySet (on the right side) as a more specialized object than frozenset

Re: __eq__() inconvenience when subclassing set

2009-10-30 Thread Jess Austin
On Oct 29, 10:41 pm, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: We know the last test fails because the == logic fails to recognize mySet   (on the right side) as a more specialized object than frozenset (on the   left side), because set and frozenset don't have a common base type  

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Jess Austin
On Oct 28, 10:07 pm, Mick Krippendorf mad.m...@gmx.de wrote: You could just overwrite set and frozenset: class eqmixin(object):     def __eq__(self, other):         print called %s.__eq__() % self.__class__         if isinstance(other, (set, frozenset)):             return True        

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Mick Krippendorf
Jess Austin wrote: That's nice, but it means that everyone who imports my class will have to import the monkeypatch of frozenset, as well. I'm not sure I want that. More ruby than python, ne? I thought it was only a toy class? Mick. -- http://mail.python.org/mailman/listinfo/python-list

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Jess Austin
On Oct 29, 3:54 pm, Mick Krippendorf mad.m...@gmx.de wrote: Jess Austin wrote: That's nice, but it means that everyone who imports my class will have to import the monkeypatch of frozenset, as well.  I'm not sure I want that.  More ruby than python, ne? I thought it was only a toy class?

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Gabriel Genellina
En Wed, 28 Oct 2009 23:12:53 -0300, Jess Austin jess.aus...@gmail.com escribió: class mySet(set): ... def __eq__(self, other): ... print called mySet.__eq__()! ... if isinstance(other, (set, frozenset)): ... return True ... return set.__eq__(self,

__eq__() inconvenience when subclassing set

2009-10-28 Thread Jess Austin
I'm subclassing set, and redefining __eq__(). I'd appreciate any relevant advice. class mySet(set): ... def __eq__(self, other): ... print called mySet.__eq__()! ... if isinstance(other, (set, frozenset)): ... return True ... return set.__eq__(self,

Re: __eq__() inconvenience when subclassing set

2009-10-28 Thread Mick Krippendorf
Jess Austin schrieb: frozenset([1]) == mySet() False frozenset doesn't use mySet.__eq__() because mySet is not a subclass of frozenset as it is for set. You could just overwrite set and frozenset: class eqmixin(object): def __eq__(self, other): print called %s.__eq__() %