Implement eq, ne for slice

[HyeockJinKim]

Issue: #98

[sbinet]

just thinking out loud, but any reason we don't implement one in terms of the other?

[HyeockJinKim]

I looked at the range.go and list.go implementations, so I implemented __eq__ and __ne__ in the same way.
Should I create and call a private function for the common part?

[sbinet]

not necessarily. it was just a silly question from my end.
I was just wondering whether there were a more philosophical underlying reason for this.

consistency w/ other parts of the code SGTM.
(one could also argue for reducing the number of function calls)

[HyeockJinKim]

Looking at the dict.go and set.go, there is some code written that calls __eq__ in __ne__, so I called eq.

[ncw]

looking at the dict.go code and set.go code it is actually wrong and I think your PR #110 fixes up the set case.

What you've written here is much better.

However the fact that we've made the same mistake more than once in the code base makes me think we should factor this out and in the process tighten it up more.

So how about something like this in slice, set, dict and anywhere else we make a __ne__ from an __eq__

func (a *Set) M__ne__(other Object) (Object, error) {
	return NotEq(a.M__eq__(other))
}

And then put something like this in py/bool.go

// NotEq is used to invert the result of an __eq__ call
func NotEq(eq Object, err error) (Object, error) {
	if err != nil {
		return nil, err
	}
	switch eq {
	case True:
		return False, nil
	case False:
		return True, nil
	case NotImplemented:
		return eq, nil
	}
	return nil, ExceptionNewf(TypeError, "__eq__ returned a non bool: (type %s)", eq.Type().Name)
}

(all code untested!)

[HyeockJinKim]

Should I handle values ​​other than True, False and NotImplemented?
Do we have to return an exception even if we handle it?

[ncw]

As far as I know eq should only ever return True, False or NotImplemented but python can use any value as a truthy value so...

Perhaps more Pythonic might be this which is equivalent to using the not operator on the result.

func NotEq(eq Object, err error) (Object, error) {
	if err != nil {
		return nil, err
	}
	if eq == NotImplemented {
		return eq, nil
	}
	return Not(eq)
}

Do we have to return an exception even if we handle it?

We need to return the exception from the __eq__ call.

I just wrote NotEq like that do it had a convenient way to call it NotEq(a.M__eq__(other))

[HyeockJinKim]

I understand. Would you please review again?
And when this PR is merged, I will modify #110 to use NotEq.

[ncw]

This looks great now - thank you.

Apologies for the delay merging.