Re: [Python-Dev] Equality on method objects
On Mon, Mar 10, 2008 at 9:20 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 10, 2008 at 4:26 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > > Hi Phillip, > > > > > > On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote: > > > I did not, however, need the equality of bound methods to be based on > > > object value equality, just value identity. > > > > > > ...at least until recently, anyway. I do have one library that wants > > > to have equality-based comparison of im_self. What I ended up doing > > > is writing code that tests what the current Python interpreter is > > > doing, and if necessary implements a special method type, just for > > > purposes of working around the absence of im_self equality > > > testing. However, it's a pretty specialized case (...) > > > > I found myself in exactly the same case: a pretty specialized example > > where I wanted bound methods to use im_self equality rather than > > identity, solved by writing my own bound-method-like object. But that's > > not really hard to do, and the general tendency (which matches my own > > opinion too) seems to be that using im_self identity is less surprizing. > > > > In general, "x.append" is interchangeable with "x.append" even if > > "x.append is not x.append", so let's go for the least surprizing > > behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func". > > Objection? > > +1 > > -- > Adam Olsen, aka Rhamphoryncus > +1 here too. For 2.6 as well as 3.0. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
On Mon, Mar 10, 2008 at 4:26 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi Phillip, > > > On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote: > > I did not, however, need the equality of bound methods to be based on > > object value equality, just value identity. > > > > ...at least until recently, anyway. I do have one library that wants > > to have equality-based comparison of im_self. What I ended up doing > > is writing code that tests what the current Python interpreter is > > doing, and if necessary implements a special method type, just for > > purposes of working around the absence of im_self equality > > testing. However, it's a pretty specialized case (...) > > I found myself in exactly the same case: a pretty specialized example > where I wanted bound methods to use im_self equality rather than > identity, solved by writing my own bound-method-like object. But that's > not really hard to do, and the general tendency (which matches my own > opinion too) seems to be that using im_self identity is less surprizing. > > In general, "x.append" is interchangeable with "x.append" even if > "x.append is not x.append", so let's go for the least surprizing > behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func". > Objection? +1 -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
Phillip J. Eby wrote: > At 12:26 PM 3/10/2008 +0100, Armin Rigo wrote: >> In general, "x.append" is interchangeable with "x.append" even if >> "x.append is not x.append", so let's go for the least surprizing >> behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func". >> Objection? > > Nope; that's exactly what I proposed at the end of the email quoted above. +1 here - this is the behaviour I would expect if attempting to provide a called-once-only guarantee for a callback list. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
At 12:26 PM 3/10/2008 +0100, Armin Rigo wrote: >Hi Phillip, > >On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote: > > I did not, however, need the equality of bound methods to be based on > > object value equality, just value identity. > > > > ...at least until recently, anyway. I do have one library that wants > > to have equality-based comparison of im_self. What I ended up doing > > is writing code that tests what the current Python interpreter is > > doing, and if necessary implements a special method type, just for > > purposes of working around the absence of im_self equality > > testing. However, it's a pretty specialized case (...) > >I found myself in exactly the same case: a pretty specialized example >where I wanted bound methods to use im_self equality rather than >identity, solved by writing my own bound-method-like object. But that's >not really hard to do, and the general tendency (which matches my own >opinion too) seems to be that using im_self identity is less surprizing. > >In general, "x.append" is interchangeable with "x.append" even if >"x.append is not x.append", so let's go for the least surprizing >behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func". >Objection? Nope; that's exactly what I proposed at the end of the email quoted above. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
Hi Phillip, On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote: > I did not, however, need the equality of bound methods to be based on > object value equality, just value identity. > > ...at least until recently, anyway. I do have one library that wants > to have equality-based comparison of im_self. What I ended up doing > is writing code that tests what the current Python interpreter is > doing, and if necessary implements a special method type, just for > purposes of working around the absence of im_self equality > testing. However, it's a pretty specialized case (...) I found myself in exactly the same case: a pretty specialized example where I wanted bound methods to use im_self equality rather than identity, solved by writing my own bound-method-like object. But that's not really hard to do, and the general tendency (which matches my own opinion too) seems to be that using im_self identity is less surprizing. In general, "x.append" is interchangeable with "x.append" even if "x.append is not x.append", so let's go for the least surprizing behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func". Objection? A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
At 01:59 PM 3/9/2008 -0800, Guido van Rossum wrote: >Do we have much of a use case for this? I've often had APIs that take a callback that promise to only invoke the callback once, even if it's added more than once. And I've used dicts, lists, and sets for same. I did not, however, need the equality of bound methods to be based on object value equality, just value identity. ...at least until recently, anyway. I do have one library that wants to have equality-based comparison of im_self. What I ended up doing is writing code that tests what the current Python interpreter is doing, and if necessary implements a special method type, just for purposes of working around the absence of im_self equality testing. However, it's a pretty specialized case, and if I didn't have to support older Python versions I'd just use partial() -- assuming that partial() supports hashing and equality comparisons, that is, which I haven't checked. I imagine hashing a partial() might be at least as tricky as getting bound methods "right". :) >That said, if there's a use case, I agree that it would be okay with >basing the equality of x.foo and y.foo on whether x and y are the same >object, not on whether x==y (consider 0 .__add__ == 0.0 .__add__). +1 for making two bound methods m1 and m2 equal if and only if "m1.im_self is m2.im_self and m1.im_func==m2.im_func", and making the hash based on im_func and id(im_self). I don't think that the im_func comparison should be identity-based by default, however. (The im_func could be another bound method, for example.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
Guido van Rossum wrote: > That said, if there's a use case, I agree that it would be okay with > basing the equality of x.foo and y.foo on whether x and y are the same > object, not on whether x==y (consider 0 .__add__ == 0.0 .__add__). The use case in the issue tracker was maintaining a collection of unique callbacks, some of which could be bound methods - the current behaviour is actively harmful to that use case, since some of the later callbacks may fail to register properly (due to their self comparing equal to another instance of the same type that already had its callback method in the list). That same use case is what makes it useful to consider the same method on a single object to be equal - there is little point in having a bound method like "x.notify" in a callback list twice. So for myself, +1 on acknowledging issue 1617161 as a bug and fixing it as Armin suggests. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
On Sun, Mar 9, 2008 at 9:51 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Sun, Mar 9, 2008 at 9:02 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > In Python 2.5, I made an attempt to make equality consistent for the > > various built-in and user-defined method types. I failed, though, as > > explained in http://bugs.python.org/issue1617161. The outcome of this > > discussion is that, first of all, we need to decide which behavior is > > "correct": > > > > >>> [].append == [].append > > True or False? > > > > (See the issue tracker for why the answer should probably be False.) > > > > The general question is: if x.foo and y.foo resolve to the same method, > > should "x.foo == y.foo" delegate to "x == y" or be based on "x is y"? > > > > The behavior about this has always been purely accidental, with three > > different results for user-defined methods versus built-in methods > > versus method wrappers (those who know what the latter are, raise your > > hand). > > > > (Yes, Python < 2.5 managed three different behaviors instead of just > > two: one of the types (don't ask me which) would base its equality on > > the identity of the 'self', but still compute its hash from the hash of > > 'self'...) > > They should only compare equal if interchangeable. In the case of a > mutable container (ie list), a value comparison of self is irrelevant > garbage, so it should always be compared (and hashed) based on > identity. > > IOW, "x = []; x.append == x.append" should be True, and everything > else should be False. Perhaps. I think we should approach this from the perspective of what is the most useful behavior that is straightforward to implement, not what is "right" (since there is more than one "right"). Do we have much of a use case for this? If not, I'd be okay with not providing these various forms of bound methods with equality at all, and just fall back on 'is'. While it may be surprising that x.append is not x.append, it should be no more surprising than x+1 is not x+1 under certain circumstances, and both actually provide a useful insight into the implementation. That said, if there's a use case, I agree that it would be okay with basing the equality of x.foo and y.foo on whether x and y are the same object, not on whether x==y (consider 0 .__add__ == 0.0 .__add__). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
On Sun, Mar 9, 2008 at 9:02 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi all, > > In Python 2.5, I made an attempt to make equality consistent for the > various built-in and user-defined method types. I failed, though, as > explained in http://bugs.python.org/issue1617161. The outcome of this > discussion is that, first of all, we need to decide which behavior is > "correct": > > >>> [].append == [].append > True or False? > > (See the issue tracker for why the answer should probably be False.) > > The general question is: if x.foo and y.foo resolve to the same method, > should "x.foo == y.foo" delegate to "x == y" or be based on "x is y"? > > The behavior about this has always been purely accidental, with three > different results for user-defined methods versus built-in methods > versus method wrappers (those who know what the latter are, raise your > hand). > > (Yes, Python < 2.5 managed three different behaviors instead of just > two: one of the types (don't ask me which) would base its equality on > the identity of the 'self', but still compute its hash from the hash of > 'self'...) They should only compare equal if interchangeable. In the case of a mutable container (ie list), a value comparison of self is irrelevant garbage, so it should always be compared (and hashed) based on identity. IOW, "x = []; x.append == x.append" should be True, and everything else should be False. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Equality on method objects
Hi all, In Python 2.5, I made an attempt to make equality consistent for the various built-in and user-defined method types. I failed, though, as explained in http://bugs.python.org/issue1617161. The outcome of this discussion is that, first of all, we need to decide which behavior is "correct": >>> [].append == [].append True or False? (See the issue tracker for why the answer should probably be False.) The general question is: if x.foo and y.foo resolve to the same method, should "x.foo == y.foo" delegate to "x == y" or be based on "x is y"? The behavior about this has always been purely accidental, with three different results for user-defined methods versus built-in methods versus method wrappers (those who know what the latter are, raise your hand). (Yes, Python < 2.5 managed three different behaviors instead of just two: one of the types (don't ask me which) would base its equality on the identity of the 'self', but still compute its hash from the hash of 'self'...) A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
