[Python-ideas] float('∞')=float('inf')

[Joshua Landau]

On 14 July 2013 03:07, Steven D'Aprano <steve at pearwood.info> wrote:
> On 14/07/13 11:39, Joshua Landau wrote:
>>
>> On 14 July 2013 02:24, Steven D'Aprano <steve at pearwood.info> wrote:
>>>
>>> On 14/07/13 03:25, Philipp A. wrote:
>>>>
>>>>
>>>> so don’t be silly everyone. the question is if float('∞') should work
>>>> and
>>>> i
>>>> say “why the hell not”
>>>
>>>
>>>
>>>
>>> Firstly, let me say that I personally love the idea of float('∞')
>>> working.
>>> Or even having literal ∞ recognised as float('inf') (or perhaps that
>>> should
>>> be Decimal('inf')?).
>>>
>>> But I'm still voting -1 on this proposal. If the best argument in favour
>>> is
>>> "why the hell not?", then whatever benefit we might gain is truly tiny.
>>> So
>>> tiny that the benefit is probably smaller than the cost. And yes, there
>>> is a
>>> cost, there is always a cost. There are one-off costs:
>>
>>
>>
>> That wasn't the best reason. The best reason was given by the OP, who
>> said that it was for data input. If you receive data that uses ∞, then
>> it's useful.
>
>
> Only if you are expecting to get float('inf') as the answer. Just because
> IEEE 754 floating point supports INFs and NANs doesn't mean that any
> particular application needs or wants to support them.
>
> My guess is that for every app that actively would benefit from this, there
> is another app that would actively have to counter-act this feature, and
> another 50 that simply don't care. For apps that actively do want to support
> INFs, doing a text transformation ∞ -> 'inf' before calling float is
> trivial.

I think it's the best reason because "why not?" is a worse one. Hence
it's the best reason.

Also, name a single app where accepting unicode infinity is bad.

>>> - somebody has to program this feature;
>>> - write tests for it;
>>> - write documentation;
>>>
>>> and on-going costs:
>>>
>>> - that's one more thing for every user to learn;
>>
>>
>> Doesn't apply here.
>
>
> Of course it does. Do you think that people are born knowing that float('∞')
> returns an IEEE 754 floating point INF? It's a feature that needs to be
> learned.

No it's not. It needs to be learned if you use float on data that can
return "∞", excluding data directly from humans (where you don't need
to know about it much as most people don't need to know about
internationalisation). This is not a burden that most people will
feel.

>>> - programmers will have to take this feature into account whenever they
>>> use
>>> float.
>>
>>
>> This isn't true -- most uses of float(...) don't care about the
>> internationalisation aspect either. Only a minority of cases will need
>> to account for this.
>
>
> Correct. And? Most users won't care. Of those that do care, some will be
> annoyed because previously they could rely on float('∞') raising an
> exception, and no longer can.

Agreed. But that was a contradiction of the statement "programmers
will have to take this feature into account whenever they use float"
which it adequately contradicts.


>>> Here is a simple implementation that supports ∞, +∞ and -∞.
>>>
>>>
>>> _float = float
>>>
>>> def float(arg):
>>>      if isinstance(arg, str):
>>>          arg = arg.replace('∞', 'inf')
>>>      return _float(arg)
>>>
>>>
>>> Hands up anyone who already uses this, or something like it, in their
>>> code?
>>> Anyone? Given how trivial it is to build this functionality if you need
>>> it,
>>> if you haven't already done so, chances are that you don't need it, even
>>> if
>>> you think you want it.
>>
>>
>> I'd hope not, because that's broken code. All the more reason to
>> accept the proposal.
>
>
> How is it broken? True, it accepts '∞inity' as well as 'infinity', but
> that's a feature, not a bug.

First I will admit that originally I misread the code so my tone was
more pronounced than it should've been. I posted seconds before I
realised, but decided that it wasn't worth changing.

Secondly, I'm not convinced that accepting "∞inity" a feature.
Thirdly, even assuming it was, the code was written as if it were a
direct stand-in for the proposal, which it is not and thus the code is
buggy. Of course, it would be as simple as replacing "∞" with
"infinity" instead of "inf", AFAICT -- *assuming* that you don't mind
that it "breaks" the returned exceptions.