Feature: Defining Equals (and local deletion of QuerySet)

[SovcikJoe]

Hi Miles,

so I noticed a while back that if I want to compare two Objects I get False no matter what I do, unless I directly compare their objectId's for example.

So I wanted to implement this myself using

  def __hash__(self):
        return hash(self.obj)

    def __eq__(self,other):
        pdb.set_trace()
        print('__eq__()')
        return self.objectId == other.objectId

And I added this code to query.Queryset as I am working with Querysets. (BTW pdb is there just so I can see what's going on but the code never gets triggered)

So then I would expect that if I do

queryset[0] == samequeryset[0]

That it would return True. But it still keeps returning False.

As I am guessing I am not understanding something here, I also added the code to ParseType and QueryManager. To no appeal.

Do you know which object would be a proper place to put this code in?

I was also implementing a (local)delete function for Queryset [ something like list.remove(x) ]as well as that's something I needed badly. And I got something now so I was wondering if you'd be interested in me submitting this (and adding it to the , I am guessing , Queryset Class. I already tried using delitem method with no success again so I just implemented a public function for myself.

I would love to contribute so let me know what you think/potential feedback.

[milesrichardson]

@SovcikJoe

I'm not sure why your __eq__ is not working, however I have not looked into it much.

But I would be VERY hesitant to add this functionality. Since Python is a pass-by-reference language, overriding == to compare attributes of the objects, instead of the address of the python objects, violates expectations based on Python defaults. While this might be okay in a new library (if well documented), it could break existing code.

What if you have two copies of the same Parse object (i.e., the same objectId), but you modify a property of one of them, but not the other? In that case would you want them to be "equal"?

Because the notion of "equality" in Python can get very thorny depending on what you want to do, it can introduce a lot of unforeseen bugs. For that reason, I'm not interested in a pull request implementing this functionality. The cost does not seem worth the small benefit.

However, if you're interested in implementing it in your own fork, these links might be helpful:

http://stackoverflow.com/questions/3076967/python-is-this-an-ok-way-of-overriding-eq-and-hash

http://stackoverflow.com/questions/390250/elegant-ways-to-support-equivalence-equality-in-python-classes

Miles