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 Austin Bingham, christian.heimes, facundobatista, mark.dickinson, rhettinger, robert_smallshire, serhiy.storchaka, skrah, tim.peters
Date 2018-03-11.04:58:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1520744283.02.0.467229070634.issue26680@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry Robert, but I object to this going forward.

1) We do not and should not require that every float() method also be in int():

   >>> set(dir(float)) - set(dir(int))			 
   {'fromhex', 'hex', 'is_integer', '__getformat__', '__setformat__', 
    'as_integer_ratio'}

2) Your use case is trivially solved in a portable, trivial, and readable way:

   a == int(a)

3) I really don't want to clutter the other types with this method when it does nothing useful for those types.  In particular, I expect that the presence of "is_integer()" in the int() class will likely create more confusion than it solves (perhaps not for you, but for the vast majority of users, none of whom have ever requested this behavior over the entire history of the language).

4) Also, I don't what this to have to propagate to every project that ever registers their custom numeric types with the numeric tower.  Adding this method to the tower is essentially making a requirement that everyone, everywhere must add this method.   That is not in the spirit of what the ABCs are all about -- they mostly require a small and useful subset of the behaviors of the related concrete classes (i.e. the concrete collections all have more methods than are required by their collections.abc counterparts).

5) Lastly, the spirit of the decimal module was to stick as closely as possible to the decimal specification and assiduously avoid extending the spec with new inventions (risking duplication of functionality, risking non-portability with other implementations, risking not handling special values in a way that is consistent with the spec, risking our going down a path that intentionally not chosen by the spec creators, or risking being at odds with subsequent updates to the spec).
History
Date User Action Args
2018-03-11 04:58:03rhettingersetrecipients: + rhettinger, tim.peters, facundobatista, mark.dickinson, christian.heimes, skrah, serhiy.storchaka, robert_smallshire, Austin Bingham
2018-03-11 04:58:03rhettingersetmessageid: <1520744283.02.0.467229070634.issue26680@psf.upfronthosting.co.za>
2018-03-11 04:58:03rhettingerlinkissue26680 messages
2018-03-11 04:58:00rhettingercreate