I think that 'equivalent' functools.partial objects should compare equal, so the following snippet SHOULD print True:

>>> import functools
>>> f = lambda x: x
>>> a = functools.partial(f, 42)
>>> b = functools.partial(f, 42)
>>> a == b
False
>>>

Even equivalent functions don't compare as equal:

   >>> (lambda x: x*x) == (lambda x: x*x)
   False

Sure.  I'm not sure 'equivalent' is the word I should have used.

I suggest (and I would have expected) that partial instances (a, b) should compare equal when

  a.func == b.func \
  and a.args == b.args \
  and a.keywords == b.keywords

Function equality is based on identity, as inherited from object. But there's a precedent for this idea in method_richcompare, which compares the method's __func__ and __self__: 

http://hg.python.org/cpython/file/04f714765c13/Objects/classobject.c#l208

But since the two partial instances are (conceptually, I don't care how they are implemented) two separate functions, then reasoning by analogy from two identical functions not comparing equal, I would expect two partial instances to not compare equal.

Of course, as soon as I hit send, I had second thoughts :).  I guess a partial is a binding, not a function.

My usecase is: I create kind of bound methods with functools.partial.

Apologies for the confusion by using the word 'equivalent'; what I mean is that partial instances should (IMO) compare equal when they contain the same function and args/keywords which compare equal.

I guess functools.partialmethod has the same problem and I would suggest the same fix/enhancement but I have not used them yet because I have to write python2/3 compatible code.

Anyway; if this behaviour is not seen as a bug then it is probably python-ideas material, but I'm too tired to start a discussion there atm.

> I guess a partial is a binding, not a function.

Viewed in that light, it makes sense to implement same logic as used for bound methods in method_richcompare.

I have submitted a patch for the issue. Please review and give feedback.

I think the patch needs more tests, including:
- Comparing a partial against some other objects
- Comparing two partials with a different function
- Comparing two partials with different args

You also need to check each call to PyObject_RichCompareBool for error (it returns -1 on error). I believe the current implementation would silently ignore the error. This behavior should also be tested.

Rietveld is not picking up this diff, maybe because it is a git rather than an hg diff. Generating the diff with hg will make it easier to review.

Git diffs work, but this one doesn't apply cleanly. I manually fixed it and re-generated the patch. Rietveld should pick it up now.

Otherwise, what Jelle said. I'm not sure if the macro has the best name though - I'd probably name it `PyPartial_CheckExact` and reserve `PyPartial_Check` to allow checking for subclasses. Not sure if we need to add both in here, but it would be weird to have only one (even if the other is unused).

(Also, depending which of this one or #27137 gets committed first, the other patch will need to be updated. I'll probably do it since the other is mine.)

New patch with Jelle's suggestions. I completely removed the macros since we need to (potentially) call Python code with PyObject_IsInstance, and need to check for return code.

I also reverted some of the unrelated changes.

I support Jelle's comments and have added other comments.

There is a question: should partial(func) be equal to func?

Emanuel Barry if you want to take it over, I will stop and will not modify my patch further. Otherwise please let me know.

Shakur - Feel free to take over and work on it.

Serhiy - I don't think that partial(func) == func should be, in the same sense that (0, 1, 2), [0, 1, 2] and range(3) aren't equal even though they fundamentally represent the same thing.

Submitted a new patch addressing the review comments.