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

[Steven D'Aprano]

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.


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


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



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



-- 
Steven