gmpy and counting None

[Robert Kern]

Mensanator wrote:
> On Oct 14, 12:14 pm, Robert Kern <robert.k... at gmail.com> wrote:
>> Mensanator wrote:
>>> On Oct 13, 5:16 pm, Robert Kern <robert.k... at gmail.com> wrote:
>>>> Mensanator wrote:
>>>>> On Oct 13, 2:43 pm, <mma... at gmx.net> wrote:
>>>>>> Hi,
>>>>>> I just stumbled upon the following issue (I am running Debian):
>>>>>> $ python
>>>>>> Python 2.5.2 (r252:60911, Sep 29 2008, 21:15:13)
>>>>>> [GCC 4.3.2] on linux2
>>>>>> Type "help", "copyright", "credits" or "license" for more information.>>> [2, None].count(None)
>>>>>> 1
>>>>>>>>> from gmpy import mpz
>>>>>>>>> [mpz(2), None].count(None)
>>>>>> Traceback (most recent call last):
>>>>>>   File "<stdin>", line 1, in <module>
>>>>>> TypeError: coercion to gmpy.mpz type failed
>>>>>> Is this a bug in gmpy?
>>>>> Does the underlying GMP code support Nulls?
>>>> I don't think it has to. Probably, it just should implement __ne__ to return
>>>> False if it cannot coerce. Of course, the codebase is relatively old, so it may
>>>> still be using __cmp__ and __coerce__. That would make things more difficult.
>>> Ok, assuming you CAN fix it, the next question is SHOULD you
>>> fix it? Afetr all, mpz(None) will still raise an exception and
>>> wouldn't the behaviour then be inconsistent?
>> I don't think so. There is no particular reason that an implementation of __eq__
>> or __ne__ *must* coerce its arguments and raise an exception if it can't. There
>> is certainly a case to be made for __lt__ and the rest, because they imply an
>> actual numerical comparison, but __eq__ and __ne__ are used for more than
>> numerical comparison in Python. One of the great things about moving away from
>> __cmp__ to the multiple comparison methods is that the two concepts were no
>> longer entangled.
> 
> Ok.
> 
>>> When I complained that sum([]) should return None instead of 0,
>>> the general consensus was that the 0 choice is what most people
>>> expect most of the time and although there are cases where None
>>> is the logical choice, the 0 case is NOT a bug, "this behaviour
>>> is by design" and I'll just have to live with it and not use
>>> sum() if I expect the list may be empty.
>>> I would expect that you could make the same argument with respect
>>> to trying to compare an mpz to None.
>> That it was by design? Possible, but I have no evidence of such. Do you?
> 
> No, I was just saying IF it was intentional, then it's not a bug.
> Although one could argue whether the intent was appropriate. As you
> say
> above, maybe the intent needs to be re-thought.

And even then, it's not so much of a bug as a missing feature.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco