gmpy and counting None

[Guest]

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):

Is this a bug in gmpy?

If yes is there any way to issue the bug at
http://code.google.com/p/gmpy/
without creating a gmail account?


Thanks

Martin

 

[Mensanator]

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?

 

[Robert Kern]

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.

--
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

 

[casevh]

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?

If yes is there any way to issue the bug athttp://code.google.com/p/gmpy/
without creating a gmail account?

I've added it for you.

Thanks

Martin

Thanks for reporting the issue.

casevh

 

[Mensanator]

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]

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.

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? If that
is not what you meant, then I have no idea what argument you think applies to
both cases.

--
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

 

[Mensanator]

Mensanator 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

 

[Robert Kern]

Mensanator 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