[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    [Python-ideas] Re: 'Infinity' constant in Python
From:       Todd <toddrjen () gmail ! com>
Date:       2020-09-04 22:30:39
Message-ID: CAFpSVpLfP8=XGof6u0AnaV_3+eU83qj+6uVqzydpn4QBZMzA9A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Sep 4, 2020, 12:48 Cade Brown <brown.cade@gmail.com> wrote:

> I am positing that Python should contain a constant (similar to True,
> False, None), called Infinity.
>
> It would be equivalent to `float('inf')`, i.e. a floating point value
> representing a non-fininte value. It would be the positive constant;
> negative infinity could retrieved via `-Infinity`
>
> Or, to keep float representation the same, the name `inf` could be used,
> but that does not fit Python's normal choice for such identifiers (but
> indeed, this is what C uses which is the desired behavior of string
> conversion)
>
> I think there are a number of good reasons for this constant. For example:
>   * It is also a fundamental constant (similar to True, False, and None),
> and should be representable as such in the language
>   * Requiring a cast from float to string is messy, and also obviously
> less efficient (but this performance difference is likely insignificant)
>       * Further, having a function call for something that should be a
> constant is a code-smell; in general str -> float conversion may throw an
> error or anything else and I'd rather not worry about that.
>   * It would make the useful property that `eval(repr(x)) == x` for
> floating point numbers (currently, `NameError: name 'inf' is not defined`)
>
> This makes it difficult to, for example, naively serialize a list of
> floats. For example:
>
> ```
> >>> x = [1, 2, 3, 4]
> >>> repr(x)
> '[1, 2, 3, 4]'
> >>> eval(repr(x)) == x
> True
> >>> x = [1, 2, 3, float('inf')]
> >>> repr(x)
> '[1, 2, 3, inf]'
> >>> eval(repr(x)) == x
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<string>", line 1, in <module>
> NameError: name 'inf' is not defined
> ```
>
> To me, this is problematic; I would expect it to work seamlessly as it
> does with other floating point constants.
>
> A few rebuttals/claims against:
>   - Creating a new constant (Infinity) which is unassignable may break
> existing code
>


It will break an ENORMOUS amount of code.  Numpy has its own top-level
"inf" variable.  So all code that uses "from numpy import *" will break.
Pylab imports numpy in that way, so "from pylab import *" will also break.
Whether you think this is a good approach or not, a ton of tutorials
recommend doing this.  All of those tutorials will break in a way that is
very hard to fix.

>

[Attachment #5 (text/html)]

<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" \
class="gmail_attr">On Fri, Sep 4, 2020, 12:48 Cade Brown &lt;<a \
href="mailto:brown.cade@gmail.com" target="_blank" \
rel="noreferrer">brown.cade@gmail.com</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">I am positing that Python should \
contain a constant (similar to True, False, None), called Infinity.</div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif">It would be \
equivalent to `<span style="font-family:monospace">float(&#39;inf&#39;)</span>`, i.e. \
a floating point value representing a non-fininte value. It would be the positive \
constant; negative infinity could retrieved via `-Infinity`</div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif">Or, to keep \
float representation the same, the name `inf` could be used, but that does not fit \
Python&#39;s normal choice for such identifiers (but indeed, this is what C uses \
which is the desired behavior of string conversion)<br></div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think there \
are a number of good reasons for this constant. For example:</div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif">   * It is also \
a fundamental constant (similar to True, False, and None), and should be \
representable as such in the language<br></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">   * Requiring a cast from float to \
string is messy, and also obviously less efficient (but this performance difference \
is likely insignificant)</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">           * Further, having a \
function call for something that should be a constant is a code-smell; in general str \
-&gt; float conversion may throw an error or anything else and I&#39;d rather not \
worry about that.<br></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">   * It would make the useful property \
that `<span style="font-family:monospace">eval(repr(x)) == x</span>` for floating \
point numbers (currently, `<span style="font-family:monospace">NameError: name \
&#39;inf&#39; is not defined</span>`)</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">This makes it difficult to, for \
example, naively serialize a list of floats. For example:</div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div \
class="gmail_default"><span style="font-family:monospace">```</span></div><div \
class="gmail_default"><span style="font-family:monospace">&gt;&gt;&gt; x = [1, 2, 3, \
4]<br>&gt;&gt;&gt; repr(x)<br>&#39;[1, 2, 3, 4]&#39;<br>&gt;&gt;&gt; eval(repr(x)) == \
x<br>True<br>&gt;&gt;&gt; x = [1, 2, 3, float(&#39;inf&#39;)]<br>&gt;&gt;&gt; \
repr(x)<br>&#39;[1, 2, 3, inf]&#39;<br>&gt;&gt;&gt; eval(repr(x)) == x<br>Traceback \
(most recent call last):<br>   File &quot;&lt;stdin&gt;&quot;, line 1, in \
&lt;module&gt;<br>   File &quot;&lt;string&gt;&quot;, line 1, in \
&lt;module&gt;<br>NameError: name &#39;inf&#39; is not defined<br></span></div><div \
class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span \
style="font-family:monospace">```</span></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">To me, this is problematic; I would \
expect it to work seamlessly as it does with other floating point \
constants.</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">A few rebuttals/claims \
against:</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif">   - Creating a new constant \
(Infinity) which is unassignable may break existing \
code</div></div></blockquote></div><div dir="auto">  </div><div \
dir="auto"><br></div><div dir="auto">It will break an ENORMOUS amount of code.   \
Numpy has its own top-level &quot;inf&quot; variable.   So all code that uses \
&quot;from numpy import *&quot; will break.   Pylab imports numpy in that way, so \
&quot;from pylab import *&quot; will also break.   Whether you think this is a good \
approach or not, a ton of tutorials recommend doing this.   All of those tutorials \
will break in a way that is very hard to fix.</div><div class="gmail_quote" \
dir="auto"></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> \
</blockquote></div></div>



_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/GTPEHRE7VZCQD5CMCMGQ54XUBUQDUH6D/
 Code of Conduct: http://python.org/psf/codeofconduct/



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic