Also, I've seen multiple people say I suggested 'inf' as the name when I've
specifically said at least twice that it would not be my choice for the
identifier. I clearly have said 'Infinity' is the far superior choice for
Python. My comments were that currently, Python displays 'inf' as the
string representation, and that the repr function would be changed to
return the new identifier (i.e. `repr(float('inf')) == 'Infinity'`)
And, I am undecided on 'nan' semantics (`NaN` would be my choice of
identifier, in any situation), since it is (by definition) not a number.
It's kind of odd that Python has it, especially since it has 'none'. I
guess it's good for interfacing with C APIs and lower level functions that
require a float and not a generic object, but I digress. In any case, it
would be very similar to 'Infinity' constants (some differences: `float('nan')
is float('nan')` is False, whereas `NaN is NaN` would be True, but of
course `NaN == NaN` is still False)
Thanks,
----
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu
On Sat, Sep 5, 2020 at 12:44 AM Cade Brown <brown.c...@gmail.com> wrote:
> First of all, you're comparing immutable value types to dynamic objects
> which are predicated and processed based on the memory address (e.g. for
> equality testing, by default). Of course they're going to have different
> semantics, especially when converting to a unique string representation.
> A better question to ask is why does it work for *almost* all values of
> 'float' , but not infinite ones... This is a glaring hole in my opinion.
>
> Why do you think having 'inf' is better than something that means
> something to the python interpreter? I've had countless times where I've
> had to Google how to create an infinite float, and second guessed myself
> because it is very unintuitive to have to call a string conversion to get
> what amounts to a constant.
>
> The 'use case' is being able to specify a number which is constant, by a
> constant, and not requiring me to execute a function call. Further, keeping
> it the way it is harbors readability. Every time I parse code that contains
> `float('inf')` I ask myself why it is having to do this, because it seems
> like code shouldn't have to.
>
> Your argument seems to stem from the least possible Python can do (i.e. it
> doesn't HAVE to do anything more than it does currently). This mailing list
> is python-ideas, which is for ideas currently not in Python. I am aware
> that nothing *has* to be done, I am merely suggesting why it would make
> sense to add, and why it would make Python a more complete, predictable and
> frankly 'prettier' language (albeit subjective). I don't see how any of
> your points address those concerns
>
>
> On Fri, Sep 4, 2020, 10:14 PM Steven D'Aprano <st...@pearwood.info> wrote:
>
>> On Fri, Sep 04, 2020 at 09:40:55PM -0400, Cade Brown wrote:
>> > The `eval(repr(x)) == x` is not a segment of my code; rather it is part
>> of
>> > Python's description of what 'repr' should do:
>> >
>> > https://docs.python.org/3.4/library/functions.html?highlight=repr#repr
>> >
>> >
>> > Specifically: ` For many types, this function makes an attempt to
>> return a
>> > string that would yield an object with the same value when passed to
>> eval()`
>> > <https://docs.python.org/3.4/library/functions.html?highlight=repr#eval
>> >
>>
>> "For many types" and "makes an attempt".
>>
>> There has never been, and never will be, a guarantee that all objects
>> will obey that invariant. As I said, it is a Nice To Have, and it is
>> designed for convenience at the interactive interpreter.
>>
>>
>> > So everyone in this thread can stop mentioning security concerns; I'm
>> sure
>> > we're all aware of those and we should instead focus on what repr
>> should do
>> > and shouldn't do.
>>
>> You specifically said that math.inf doesn't solve your problem *because*
>> `eval(repr(x))` doesn't work. Now you are backpeddling and saying that
>> this is not your actual problem.
>>
>> (In fact it does work, if you do it correctly.)
>>
>> There are a million other objects that don't obey that invariant:
>>
>> py> x = object()
>> py> eval(repr(x)) == x
>> SyntaxError: invalid syntax
>>
>>
>> Why is float infinity so special that it needs to obey the
>> invariant?
>>
>> What's the actual problem, or problems, in your code that you are trying
>> to solve by making an infinity builtin? If there is no actual problem
>> being solved, and the only reason you want this is because:
>>
>>
>> > I think it's weird to not fulfill this promise
>>
>>
>> you don't have any sympathy from me:
>>
>> - `eval(repr(x))` is not a promise, it is a mere suggestion
>> that *some* types *try* to provide.
>>
>> - Adding a special built-in constant Infinity just to satisfy
>> this Nice To Have feature is overkill.
>>
>> - It would require float infinities to change their repr from
>> 'inf' to 'Infinity', and that will break doctests.
>>
>> - And even if that feature were satisfied by infinity, it
>> couldn't be satisfied by float NANs by their very definition:
>>
>> py> from math import nan
>> py> nan == nan
>> False
>>
>> So while the cost of adding a new Infinity builtin is small, the benefit
>> is even smaller.
>>
>>
>> --
>> Steve
>> _______________________________________________
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/AHJETD7PM6M6IKERP7NYNGYWAJBZDS27/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CEOODXMH3BB4G5HQOWINHCEUYR7PZQMM/
Code of Conduct: http://python.org/psf/codeofconduct/
