This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients christian.heimes, facundobatista, mark.dickinson, rhettinger, robert_smallshire, serhiy.storchaka, skrah, tim.peters
Date 2016-04-04.08:02:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1459756940.62.0.643621312041.issue26680@psf.upfronthosting.co.za>
In-reply-to
Content
> the functions are so simple and self-explanatory 
> that API-complexity does not really increase.

It increases complexity because it will show-up everywhere including places where it makes little sense.

One place is int objects where its meaning and purpose will seem arcane to most Python programmers.  For int objects, this is just total waste.

With the fractions module, the method is also unnecessary because integral fractions all have a denominator of 1.

With the decimal module, we were careful not to grow the API beyond what was in the spec or what was necessary to integrate it into Python (i.e. the usual magic methods).  I think that was a good decision and would like to keep it that way. 

In general, the need for this method is almost nil (it would be a very, very rare Python programmer who would ever need this, and those that might what it are perfectly capable of writing a short function to handle their own requirements).  In the OPs case, the motivation isn't inability to determine whether something is integral, it is more a desire for the test to be polymorphic with other types where the methods do not add any real value.  

The OPs notion of "absurd" behavior implies a rule that all float methods should be available for ints.  That would suggest the is_integer, hex, fromhex, and as_integer_ratio would all need to propagate to the other types as well.  I don't think we should start sliding down that slope.

Another thought is that future updates to the decimal spec could make conflicting choices about what Decimal.is_integral() would return for Decimal('Infinity').  There could be a case to be made for true, for false, for NaN, or for setting one or more of the signal flags or traps.  

I'm glad that the OP separated out the request for Decimal given that his actual use cases involve everything except Decimal.  The decimal class is intentionally not registered a Real (only as a Number) because it isn't interoperable with binary floats; hence, there has been no need to copy all the float methods into Decimal.

AFAICT, this comes down to whether to push a float method into other types where we otherwise wouldn't do it, just to save the OP from one-line function:

is_integral = lambda x:  isinstance(x, int) or isinstance(x, Fraction) and x.denominator == 1 or isinstance(x, float) and x.is_integer()
History
Date User Action Args
2016-04-04 08:02:20rhettingersetrecipients: + rhettinger, tim.peters, facundobatista, mark.dickinson, christian.heimes, skrah, serhiy.storchaka, robert_smallshire
2016-04-04 08:02:20rhettingersetmessageid: <1459756940.62.0.643621312041.issue26680@psf.upfronthosting.co.za>
2016-04-04 08:02:20rhettingerlinkissue26680 messages
2016-04-04 08:02:19rhettingercreate