Re: gmpy and counting None
- From: Mensanator <mensanator@xxxxxxx>
- Date: Tue, 14 Oct 2008 11:05:26 -0700 (PDT)
On Oct 14, 12:14 pm, Robert Kern <robert.k...@xxxxxxxxx> wrote:
Mensanator wrote:
On Oct 13, 5:16 pm, Robert Kern <robert.k...@xxxxxxxxx> wrote:
Mensanator wrote:
On Oct 13, 2:43 pm, <mma...@xxxxxxx> wrote:I don't think it has to. Probably, it just should implement __ne__ to return
Hi,Does the underlying GMP code support Nulls?
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
Traceback (most recent call last):from gmpy import mpz
[mpz(2), None].count(None)
File "<stdin>", line 1, in <module>
TypeError: coercion to gmpy.mpz type failed
Is this a bug in gmpy?
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:
if isinstance(i,NoneType):from types import *
a = [mpz(2),None,666,None,None,'harry',33.33]
nonecount = 0
for i in a:
nonecount += 1
3print nonecount
--
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 -
.
- Follow-Ups:
- Re: gmpy and counting None
- From: Robert Kern
- Re: gmpy and counting None
- References:
- gmpy and counting None
- From: mmanns
- Re: gmpy and counting None
- From: Mensanator
- Re: gmpy and counting None
- From: Robert Kern
- Re: gmpy and counting None
- From: Mensanator
- Re: gmpy and counting None
- From: Robert Kern
- gmpy and counting None
- Prev by Date: replace mothod for only one object but not for a class
- Next by Date: C API with *args and **kw
- Previous by thread: Re: gmpy and counting None
- Next by thread: Re: gmpy and counting None
- Index(es):
Relevant Pages
|
