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 robert_smallshire
Recipients christian.heimes, facundobatista, mark.dickinson, rhettinger, robert_smallshire, serhiy.storchaka, skrah, tim.peters
Date 2016-04-04.09:57:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1459763872.89.0.130321518283.issue26680@psf.upfronthosting.co.za>
In-reply-to
Content
To be clear, I'm not arguing that is_integer is in the same category as hex and fromhex; is_integer is a mathematical property of the number, whereas hex and from hex are representational. Nobody expects interoperability of string representations of the different number types.

Neither do I take issue with the general argument against enlarging the API. In fact, if float.is_integer did not exist, I would not be campaigning for it to be invented.

What I do take issue with is already having a method on float which makes sense for all Real numbers, but then not supporting it for those other Real types. This just gets in the way of programming generally in terms of *numbers* rather than concrete types, especially when the is_integer method is being advocated as the *right way* to do such a test. This is can lead to other problems as people unthinkingly convert other number types to floats, with loss of information, just to get access to this convenience method. 

I'm (really) surprised that structural typing and polymorphism over numbers carries so little weight – a cursory look at StackOverflow* shows that there are already too many people being encouraged to answer the 'is integral' question with isinstance(x, int) when that is not what they mean or need.

As a precedent we already have int.numerator, int.denominator, int.real and int.imag which are presumably using Raymond's argument are also 'total waste', but the reality is that the presence of these attributes causes no impediment to learning and makes many tasks easier with fewer special cases. When working with rationals, I frequently rely on the fact that ints implement the Rational interface.  When working with complex numbers, I frequently rely on the fact that both int and float implement the Complex interface. For example. I have used use these attributes in the constructor for a fixed-point number type, and was thankful for their existence.

I'm also happy to set the Decimal aspect of my proposal to one side as Decimal is explicitly outside the numeric tower.

This isn't about me avoiding writing trivial one-line functions or "the OPs use case". I'm trying to help you make Python more predictable and easier to use.  I'm far from the first person to be surprised by this.

I'd be happy to trade adding is_integer to the numeric tower for a deprecation notice on float.is_integer - the outcome is the same - polymorphic number types with fewer special cases.

<http://stackoverflow.com/questions/17170226/is-integer-not-working>
<http://stackoverflow.com/questions/6239967/determining-whether-an-value-is-a-whole-number-in-python/6239987#6239987>
<http://stackoverflow.com/questions/33002747/try-except-float-but-not-integer/33002796#33002796>
<http://stackoverflow.com/a/22053804/107907>
<http://stackoverflow.com/questions/36209324/trouble-using-is-integer-in-python>
History
Date User Action Args
2016-04-04 09:57:52robert_smallshiresetrecipients: + robert_smallshire, tim.peters, rhettinger, facundobatista, mark.dickinson, christian.heimes, skrah, serhiy.storchaka
2016-04-04 09:57:52robert_smallshiresetmessageid: <1459763872.89.0.130321518283.issue26680@psf.upfronthosting.co.za>
2016-04-04 09:57:52robert_smallshirelinkissue26680 messages
2016-04-04 09:57:51robert_smallshirecreate