Interesting list Validity (True/False)

[Alex Martelli]

Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:

> >>>> import gmpy
> >>>> a = 2**177149-1
> >>>> b = gmpy.mpz(2**177149-1)
> >>>> a==b
> > True
> >>>> print '%d' % (b)
> >
> > Traceback (most recent call last):
> >   File "<pyshell#4>", line 1, in <module>
> >     print '%d' % (b)
> > TypeError: int argument required
> >
> > So although the comparison operator is smart enough to realize
> > the equivalency of numeric types and do the type conversion,
> > the print statement isn't so smart.
> 
> This is up to the gmpy designers/writers/maintainers. Anyone writing a
> class chooses which features to implement, which ones to omit, how to
> implement them, etc. The code may contain bugs, may not be efficient, may
> not behave exactly as the users expect, may not have anticipated all usage
> scenarios, a long etc. In this case, probably the gmpy writers have chosen
> not to allow to convert to int, and they may have good reasons to not do
> that (I don't know what platform are you working in, but I feel that your
> b object is somewhat larger than sys.maxint...).

The gmpy designer, writer and maintainer (all in the singular -- that's
me) has NOT chosen anything of the sort.  gmpy.mpz does implement
__int__ and __long__ -- but '%d'%somempzinstance chooses not to call
either of them.  sys.maxint has nothing to do with the case:
'%d'%somelonginstance DOES work just fine -- hey, even a *float*
instance formats just fine here (it gets truncated).  I personally
consider this a bug in %d-formatting, definitely NOT in gmpy.


Alex