Mark Dickinson wrote:
> On Dec 8, 2:24 pm, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
>> So, I would much prefer a language change. I am not competent to even
>> propose one properly, but I'll try.
> I don't see any technical problems in what you propose: as
> far as I can see it's entirely feasible. However:
>> should. On the minus side there would be the difference between
>> '__equal__' and '__eq__' to confuse people.
> I think this is exactly what makes the idea a non-starter. There
> are already enough questions on the lists about when to use 'is'
> and when to use '==', without adding an 'equals' function into
> the mix. It would add significant extra complexity to the core
> language, for questionable (IMO) gain.
So:
It is perfectly acceptable behaviour to have __eq__ return a value that
cannot be cast to a boolean, but it still does break the python list. The
fixes proposed so far all get the thumbs down, for various good reasons.
How about:
- Define a new built-in Exception
BoolNotDefinedError(ValueError)
- Have list.__contains__ (etc.) use the following comparison internally:
def newCollectionTest(x,y):
if x is y:
return True
else:
try:
return bool(x == y)
except BoolNotDefinedError:
return False
- Recommend that numpy.array.__nonzero__ and similar cases
raise BoolNotDefinedError instead of ValueError
Objects that choose to raise BoolNotDefinedError will now work in lists,
with identity semantics.
Objects that do not raise BoolNotDefinedError have no change in behaviour.
Remains to be seen how hard it is to implement, and how much it slows down
list.__contains__
Rasmus
---------------------------------------------------------------------------
Dr. Rasmus H. Fogh Email: [EMAIL PROTECTED]
Dept. of Biochemistry, University of Cambridge,
80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
--
http://mail.python.org/mailman/listinfo/python-list
