Steven D'Aprano added the comment:
On Tue, Sep 06, 2016 at 05:59:08PM +0000, Mark Dickinson wrote:
> Why do you single out `int` for special treatment,
Mostly as a demonstration for what could be done, not necessarily as
what should be done. Secondly as a potential optimization. Why go to the
expense of converting something to a float when there's a much
cheaper(?) test?
> but not `Fraction` or `Decimal`?
They're not built-ins. They would have to be imported first, before you
can test for their types. That could be costly, and it would rarely be
necessary.
> How should the implementation handle Fraction objects, and why?
If some hypothetical subclass of Fraction provides a NAN or INF value,
trust that float(x) of those values will return a float NAN or INF. If
the conversion overflows, the value isn't a NAN or INF.
> How should the implementation handle a Fraction-like object
> implemented by a user?
As above.
> Why only objects of exact type `int`, but not instances of subclasses?
Subclass of int might hypothetically implement their own NAN or INF
values. In which case, trust that MyInt('nan').__float__() will return a
NAN float as it is supposed to.
> Your suggestion replaces a straightforward
> mental model (math.isnan converts its input to float, then operates on
> it, just like almost all other math module functions) with something
> more complicated.
Not more complicated. An even more simple *model*. The existing model
for (let's say isnan):
"Convert the number x to a float, which may Overflow, then return
whether the float is a NAN."
Versus the even simpler model:
"Return whether the number x is a NAN."
(Which of course hides a more complex *implementation*.)
Versus the practice of pushing the complexity onto the users:
"Oh gods, what sort of number is my x? If I pass it to math.isnan, will
it blow up? Better wrap it in a try...except ValueError just in case.
[Later] Ah, dammit, I meant OverflowError! Oh no, is there an
UnderflowError for Fractions?"
I guess the argument boils down to whether we want to prioritise
simplicity or usefulness in the math module.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue27975>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
