Gabriel Genellina <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list