On Oct 14, 12:14 pm, Robert Kern <[EMAIL PROTECTED]> wrote:
> Mensanator wrote:
> > On Oct 13, 5:16 pm, Robert Kern <[EMAIL PROTECTED]> wrote:
> >> Mensanator wrote:
> >>> On Oct 13, 2:43 pm, <[EMAIL PROTECTED]> 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.
> If that
> is not what you meant, then I have no idea what argument you think applies to
> both cases.
Ok, forget that. It just seems to me that since .count(None)
and mpz(None) both produce exceptions, _I_ don't see a problem.
And there _IS_ a workaround:
>>> from types import *
>>> a = [mpz(2),None,666,None,None,'harry',33.33]
>>> nonecount = 0
>>> for i in a:
if isinstance(i,NoneType):
nonecount += 1
>>> print nonecount
3
>
> --
> 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 -
--
http://mail.python.org/mailman/listinfo/python-list
