gmpy and counting None

[Mensanator]

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?

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.

>
> --
> 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- Hide quoted text -
>
> - Show quoted text -