Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:

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).

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to