On 26 Jul., 19:20, Michele Simionato <[EMAIL PROTECTED]> wrote: > On Jul 26, 5:28 pm, [EMAIL PROTECTED] (Aahz) wrote: > > > IMO, you made a big mistake in combining your point with two other meaty > > issues (whether method definitions should include self and whether != > > should use __eq__() as a fallback). > <snip> > > If solid discussion > > is your goal, I suggest that you wait a couple of weeks and start over > > with a brand-new thread. > > I fully subscribe this. The point about __eq__ is legitimate and could > be discussed with quite tones. > I was bitten by this surprising behavior just a few > days ago, I had defined __eq__ and I expected __neq__ > to be defined in the obvious way. I saw that it was > not the case and I figured out immediately that > I had to override __neq__ explicitely (I have > the "explicit is better than implicit" mantra > ingrained in my mind too), I did so and everything > worked out as a charm. Total time loss: five minutes. > So, it is not a big point. Still I think > that it would make sense to automatically > define __neq__ as the negation of __eq__. > I suppose the developers did not want to make a special > case in the implementation and this is also a legitimate > concern. > > Michele Simionato
Incidentally I knew that I had to overload the negation of __eq__ explicitely and did so writing an __neq__ method. A few minutes later I found out it's not __neq__ but __ne__. So another few minutes were lost. -- http://mail.python.org/mailman/listinfo/python-list
