[Python-ideas] Re: 'Infinity' constant in Python
Jeffrey Kintscher writes:
> "from foo import *" is a really lazy programming practice
However much corporate policies and educators may deprecate widely
adopted coding practices, complaining about them will get you
disliked, and nothing else.
If you want an Infinity constant adopted, please tell us why this has
such huge benefits as opposed to the spelling "float('inf')". See
Cade Brown's posts, you don't need to (and shouldn't) repeat them. I
find them unpersuasive; I see the point, but I don't think they
overcomes the principle that this is a relatively rarely used
facility, and so doesn't need to be built-in.
Also someone needs to explain how to avoid the debacle that was the
the name collisions with True and False when the bool type was
introduced.
___
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/SGK7XZRYUQQVZZXSMVR4PY2SPVMN4TBC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
05.09.20 01:10, Cade Brown пише: > I mentioned that in my post; however it doesn't satisfy the problems I > have (mainly being that eval(repr(x))==x) It cannot be satisfied if x is a NaN. ___ 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/4EXDPUGMQ5KXLD7672K4DJQ47A5UYJ75/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
05.09.20 01:43, Greg Ewing пише: > On 5/09/20 10:15 am, Chris Angelico wrote: >> Remember that if this matters to you, you can "from math import inf". > > But you still need to use full eval on your repr, which could > be a serious security problem in some contexts. If it were a > built-in constant, ast.literal_eval could be used instead. It is better to use float() instead of ast.literal_eval(). ast.literal_eval() is not a "safe eval", it can crash the interpreter or use enormous CPU time. It can be used to organize DOS attacks. ___ 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/5FVYI4ROFTHVRVWFGU427VILUON35YOL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
05.09.20 03:24, Chris Angelico пише:
> But don't expect that to actually be secure. It mitigates SOME security
> threats.
>
> I think Python would do very well to have a "restricted evaluation"
> function. Looking at the source code for literal_eval, it doesn't seem
> too hard to add a check alongside the Constant handler to say "if it's
> Name, context Load, look up the name in the provided dict".
It is more hard that you think. Try ast.literal_eval('+1'*100). It
crashes before you start to walk the AST tree.
You need to implement at least your own AST parser in pure Python to
make more safe eval. And there are other vectors of attack (for example
via string-to-integer converter).
___
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/PGNKU7IAEXSGPVSAH4O5UHQCJNEZY4KQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
05.09.20 06:52, Christopher Barker пише:
> I am a -0 on this, but I think it was Greg Ewing that presented a real
> use case:
>
> There is no way to use literal_eval that gets you an inf (or NaN value).
ast.literal_eval('1e1000')
___
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/NWOR4UVNV2YJGHGXBDBXVIKMTC7MLS37/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 9/5/20 12:00 AM, Stephen J. Turnbull wrote: Jeffrey Kintscher writes: > "from foo import *" is a really lazy programming practice However much corporate policies and educators may deprecate widely adopted coding practices, complaining about them will get you disliked, and nothing else. I could say the same thing about people who make disparaging comments in mailing lists. My point was that importing "everything" into the global namespace and then finding that a new version of Python has a new global symbol that causes a symbol conflict in your code is not a reason to reject the change. If you use a problematic practice and a change to Python causes a symbol conflict for you, that's on you, not Python. //Jeff -- - From there to here, from here to there, funny things are everywhere. -- Theodore Geisel ___ 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/JJJPF4HHRSBELIHOKZCQQRXW6MSS4XI4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 05, 2020 at 11:01:33AM +0300, Serhiy Storchaka wrote:
> 05.09.20 06:52, Christopher Barker пише:
> > I am a -0 on this, but I think it was Greg Ewing that presented a real
> > use case:
> >
> > There is no way to use literal_eval that gets you an inf (or NaN value).
>
> ast.literal_eval('1e1000')
I don't think that's a language guarantee though. It should work in
Python interpreters that have IEEE-754 floats (the majority of
platforms), but I wouldn't expect it to work everywhere.
Does it work in MicroPython on small systems?
--
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/TPFOTT7UYU6A7LN2TCISD7CJY5TRWPAR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
Jeffrey Kintscher writes:
> If you use a problematic practice and a change to Python causes a
> symbol conflict for you, that's on you, not Python.
You are welcome to think that way. It's not representative of the
Python development community, though. We[1] care about breaking
existing code, even if we don't think much of it.
Furthermore, "from module import *" is implicitly blessed, not only by
that idiom itself (which requires special treatment in the parser!),
but also by the existence of the __all__ dunder, which allows module
authors to control which identifiers can be imported that way. Given
that, evidently not all instances of "from module import *" are
problematic, and which are problematic is a matter of taste. The
principle of "consenting adults" means that unless we have a good
reason, we'd rather avoid breaking *future* code that uses valid syntax.
A fairly tight sufficient condition is "there's no sane way to do it".
For example, if Serhiy's "from ast import literal_eval; literal_eval('1e1000')"
was the only way to spell infinity, there'd be an overwhelming sense
that "we gotta do something." But when we already have two ways
("float('inf')" and "from math import inf; inf") you're gonna get
float('inf') pushback instead.
Footnotes:
[1] Yeah, I think I can speak for the community on this one.
___
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/GHRHZNNPHN6WUN7PHPUI4TPI4ENOP5VC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 9/5/20 1:18 AM, Jeffrey Kintscher wrote: My point was that importing "everything" into the global namespace The only global namespace in Python is builtins [1]. Everything else is module or local. and then finding that a new version of Python has a new global symbol that causes a symbol conflict in your code is not a reason to reject the change. Actually, it is. The benefit has to be pretty big to overcome backwards compatibility concerns. If you use a problematic practice and a change to Python causes a symbol conflict for you, that's on you, not Python. An officially supported practice that is broken by Python is on Python. Again, the benefits would have to outweigh the code breakage. -- ~Ethan~ [1] `globals()` actually returns the module namespace. ___ 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/FUIROFYWS7KLS26BI4TKILI26FFQ75YX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 05, 2020 at 04:00:40PM +0900, Stephen J. Turnbull wrote: > Jeffrey Kintscher writes: > > > "from foo import *" is a really lazy programming practice > > However much corporate policies and educators may deprecate widely > adopted coding practices, complaining about them will get you > disliked, and nothing else. *scratches head in confusion* Since when did `from foo import *` suddenly become a widely adopted coding practice? Everyone I know agrees that (with very few exceptions) we should avoid star imports. I don't know anyone who argues in favour of star imports in the general case. It is permitted, but not encouraged. PEP 8 strongly discourages it: https://www.python.org/dev/peps/pep-0008/#imports Google bans it, allowing only imports of modules: https://github.com/google/styleguide/blob/gh-pages/pyguide.md (Some conditions apply, but nothing that would allow wildcard imports.) Linters warn about it: https://www.flake8rules.com/rules/F403.html The community seems to be in agreement that, for the most part, wildcard imports should be avoided, e.g. https://www.geeksforgeeks.org/why-import-star-in-python-is-a-bad-idea/ https://stackoverflow.com/questions/2386714/why-is-import-bad https://medium.com/@s16h/importing-star-in-python-88fe9e8bd4d2 and people have written tools to replace them: https://www.asmeurer.com/removestar/ Of course it is right and proper that people should be permitted to use wildcard imports. Consenting Adults applies. But I am perplexed that people seem to be arguing that we can't add new names to modules because that would break code that does a wildcard import from that module. When did that become a thing? I'm perplexed because, firstly, we have never guaranteed that modules won't add new names to their namespace. *Removing* names is a backwards- incompatible change. *Adding* names is not. Python 3.9 added numerous new names to modules, including: - ast.unparse - four new functions to the curses module - two new constants to fcntl - math.nextafter and .ulp etc. Secondly, in practice people do their wildcard imports at the start of the module, so they can make use of those names in their script or application: from tkinter import * window = Tk() If the module adds a new name that you aren't expecting and aren't using, it just sits there harmlessly in your application's namespace. It doesn't prevent you using that name for your own purposes, so it can't break your code unless you do the star import after other imports or definitions. Sure, you can do that star import in the middle of your code. But consenting adults applies. If you do that, you're supposed to know what you are doing. So we seem to be worrying about a non-problem here. Adding a new Infinity name to builtins, or some other module, won't break backwards compatibility. But what will break backwards compatibility is either: - making Infinity a keyword, like None; - or changing the repr of math.inf to 'Infinity'. [Stephen] > Also someone needs to explain how to avoid the debacle that was the > the name collisions with True and False when the bool type was > introduced. What debacle are you referring to? Are you referring to the addition of the bools in the 2.2.1 bugfix release? If so, we avoid that these days by just not adding new features to bugfix releases. I don't know what name collisions you are referring to. In 2.2.1, new builtins bool (a function), True (the int 1) and False (the int 0) where added to allow people to backport code written for 2.3 which contained the proper bool type and special True/False singletons. Adding these didn't cause name collisions. If your module already included globals False = 0 True = not False they would quitely and harmlessly shadow the builtins and all was well. The whole transition was remarkable smooth: - PEP 285 introduced a new builtin bool type, with two named singletons True and False; https://www.python.org/dev/peps/pep-0285/ - a bool *function*, with two named values True=1 and False=0, were retroactively added to 2.2.1 (adding these to a bugfix release was an annoyance, but hardly a debacle); - and the True and False names didn't become keywords until Python 3. See here for more background on it: https://python-history.blogspot.com/2013/11/story-of-none-true-false.html https://python-history.blogspot.com/2013/11/the-history-of-bool-true-and-false.html -- 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/2G63DIJQ3VNAKQSS3NXRRQZ6G744GX33/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Fri, Sep 04, 2020 at 06:30:39PM -0400, Todd wrote: > 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. Yeah no. py> import builtins py> builtins.inf = "Hello world!" py> inf 'Hello world!' py> from numpy import * py> inf inf Making inf a keyword would certainly break code, but adding it to builtins would not. By the way, the numpy inf is a float, so literally the same value and type as the proposed inf/Infinity builtin. The only way you could tell them apart is by identity tests. -- 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/73Z5N3I455Z4HJ7UVA77MKUSGZ57WEWI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
> 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. The fact that so many modules and packages must define an 'inf' is, to me, a signal that such a constant WOULD be useful. All of them (should) be referring to the same value, anyways, so why not make a global constant instead? You can't argue that 'no one needs an infinity constant' and yet also giving evidence of code breakage of everyone having to define their own infinity constant. Surely you must see that these reasons are why I suggested the constant in the first place. Now, obviously, numpy should probably define their own infinity just for completeness, because it is supposed to be a comprehensive package. Perhaps the infinity constant should be a builtin which can be shadowed instead of a keyword (that way, no pre-existing code would break, except really weird code that only works if 'inf' is *not* defined). *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 1:00 PM Steven D'Aprano wrote: > On Fri, Sep 04, 2020 at 06:30:39PM -0400, Todd wrote: > > > 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. > > Yeah no. > > py> import builtins > py> builtins.inf = "Hello world!" > py> inf > 'Hello world!' > py> from numpy import * > py> inf > inf > > > Making inf a keyword would certainly break code, but adding it to > builtins would not. > > By the way, the numpy inf is a float, so literally the same value and > type as the proposed inf/Infinity builtin. The only way you could > tell them apart is by identity tests. > > > > > -- > 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/73Z5N3I455Z4HJ7UVA77MKUSGZ57WEWI/ > 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/ZNYFQHEXBRFV6EDNO7CJSSKCZ2N77URU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 5, 2020 at 3:39 PM Cade Brown wrote:
> The fact that so many modules and packages must define an 'inf' is, to me,
> a signal that such a constant WOULD be useful. All of them (should) be
> referring to the same value, anyways, so why not make a global constant
> instead?
>
`pi` is a widely used constant that is defined in both numpy and math. `e`
is a widely used constant that is defined in both numpy and math. Neither
of them is included in builtins. What is different about `inf` or
`Infinity`?
The only real goal I've seen is that you hope that `x == eval(repr(x))` for
floating point numbers. But that is doomed to failure since it cannot work
for NaN by its very definition. So with your change the situation would
be: It doesn't work for floats in general, but it works for two additional
floating point values that it didn't used to work for and even that
only means that you don't want to type one import:
>>> from math import inf
>>> inf == eval(repr(inf))
True
Lots of people have noted that being able to eval a repr is only a vague
goal in Python, that works *often* at most.
---
Now if you want something genuinely useful, I wish we had an integer
infinity. There are places where `float('inf')` just isn't suitable
because of the wrong type.
Doing a grep of CPython source, it looks like `sys.maxsize` occurs 343
times, and in almost every one of them it is a stand-in for "infinity." I
am certain there are other places where "a big number" is used because no
integer infinity exists; sys.maxsize is only one spelling of that.
The general context where I'd want it is in code like this:
last = int.Infinity if not n:=smaller_last() else n
good_stuff = all_stuff[first:last+1]
Or in a similar spirit, we might be looking for a bound, and run `bound =
min(new_thing, bound)` in a loop. For that code, I need an initial value;
albeit, in that case, float inf is probably fine. And if I'm writing code
to count the number of books on my shelf, sys.maxsize is a perfectly good
starting point as well. But int.Infinity expresses the actual intention
more clearly.
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/3YHOINWHCAQXWKIDM36C225VFRLWNHND/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
You can absolutely represent pi or e with a constant (3.14159265358979)
The same cannot be said for infinity, hence why it should be a constant
rather than a function call to retrieve the value
On Sat, Sep 5, 2020, 4:08 PM David Mertz wrote:
> On Sat, Sep 5, 2020 at 3:39 PM Cade Brown wrote:
>
>> The fact that so many modules and packages must define an 'inf' is, to
>> me, a signal that such a constant WOULD be useful. All of them (should) be
>> referring to the same value, anyways, so why not make a global constant
>> instead?
>>
>
> `pi` is a widely used constant that is defined in both numpy and math.
> `e` is a widely used constant that is defined in both numpy and math.
> Neither of them is included in builtins. What is different about `inf` or
> `Infinity`?
>
> The only real goal I've seen is that you hope that `x == eval(repr(x))`
> for floating point numbers. But that is doomed to failure since it cannot
> work for NaN by its very definition. So with your change the situation
> would be: It doesn't work for floats in general, but it works for two
> additional floating point values that it didn't used to work for and
> even that only means that you don't want to type one import:
>
> >>> from math import inf
> >>> inf == eval(repr(inf))
> True
>
> Lots of people have noted that being able to eval a repr is only a vague
> goal in Python, that works *often* at most.
>
> ---
>
> Now if you want something genuinely useful, I wish we had an integer
> infinity. There are places where `float('inf')` just isn't suitable
> because of the wrong type.
>
> Doing a grep of CPython source, it looks like `sys.maxsize` occurs 343
> times, and in almost every one of them it is a stand-in for "infinity." I
> am certain there are other places where "a big number" is used because no
> integer infinity exists; sys.maxsize is only one spelling of that.
>
> The general context where I'd want it is in code like this:
>
> last = int.Infinity if not n:=smaller_last() else n
> good_stuff = all_stuff[first:last+1]
>
> Or in a similar spirit, we might be looking for a bound, and run `bound =
> min(new_thing, bound)` in a loop. For that code, I need an initial value;
> albeit, in that case, float inf is probably fine. And if I'm writing code
> to count the number of books on my shelf, sys.maxsize is a perfectly good
> starting point as well. But int.Infinity expresses the actual intention
> more clearly.
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born. Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
>
___
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/OO4QLGO3A52H4WMSXTYQMMR6NRQ6FUPO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
About 20 people have pointed out that `inf` *IS* a constant. It's just in
math rather then built-ins.
On Sat, Sep 5, 2020, 5:10 PM Cade Brown wrote:
> You can absolutely represent pi or e with a constant (3.14159265358979)
>
> The same cannot be said for infinity, hence why it should be a constant
> rather than a function call to retrieve the value
>
> On Sat, Sep 5, 2020, 4:08 PM David Mertz wrote:
>
>> On Sat, Sep 5, 2020 at 3:39 PM Cade Brown wrote:
>>
>>> The fact that so many modules and packages must define an 'inf' is, to
>>> me, a signal that such a constant WOULD be useful. All of them (should) be
>>> referring to the same value, anyways, so why not make a global constant
>>> instead?
>>>
>>
>> `pi` is a widely used constant that is defined in both numpy and math.
>> `e` is a widely used constant that is defined in both numpy and math.
>> Neither of them is included in builtins. What is different about `inf` or
>> `Infinity`?
>>
>> The only real goal I've seen is that you hope that `x == eval(repr(x))`
>> for floating point numbers. But that is doomed to failure since it cannot
>> work for NaN by its very definition. So with your change the situation
>> would be: It doesn't work for floats in general, but it works for two
>> additional floating point values that it didn't used to work for and
>> even that only means that you don't want to type one import:
>>
>> >>> from math import inf
>> >>> inf == eval(repr(inf))
>> True
>>
>> Lots of people have noted that being able to eval a repr is only a vague
>> goal in Python, that works *often* at most.
>>
>> ---
>>
>> Now if you want something genuinely useful, I wish we had an integer
>> infinity. There are places where `float('inf')` just isn't suitable
>> because of the wrong type.
>>
>> Doing a grep of CPython source, it looks like `sys.maxsize` occurs 343
>> times, and in almost every one of them it is a stand-in for "infinity." I
>> am certain there are other places where "a big number" is used because no
>> integer infinity exists; sys.maxsize is only one spelling of that.
>>
>> The general context where I'd want it is in code like this:
>>
>> last = int.Infinity if not n:=smaller_last() else n
>> good_stuff = all_stuff[first:last+1]
>>
>> Or in a similar spirit, we might be looking for a bound, and run `bound =
>> min(new_thing, bound)` in a loop. For that code, I need an initial value;
>> albeit, in that case, float inf is probably fine. And if I'm writing code
>> to count the number of books on my shelf, sys.maxsize is a perfectly good
>> starting point as well. But int.Infinity expresses the actual intention
>> more clearly.
>>
>> --
>> The dead increasingly dominate and strangle both the living and the
>> not-yet born. Vampiric capital and undead corporate persons abuse
>> the lives and control the thoughts of homo faber. Ideas, once born,
>> become abortifacients against new conceptions.
>>
>
___
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/OXZVL75IVC6IKE5XFSDRLB4EQCBX2ESO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 6/09/20 8:08 am, David Mertz wrote:
Lots of people have noted that being able to eval a repr is only a vague
goal in Python, that works *often* at most.
Still, the fact that it *almost* works for floats, except for
certain specific values, is a bit annoying.
Maybe the solution is for the repr of a float to be float('inf')
instead of just 'inf'.
That still wouldn't work with literal_eval, but I've realised that
literal_eval only works on tuples, not lists, so it's of limited
use anyway.
--
Greg
___
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/EGPRIEZLA36EPRYT7ZNK5RHVAYDYAU4G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 6/09/20 8:08 am, David Mertz wrote: The only real goal I've seen is that you hope that `x == eval(repr(x))` for floating point numbers. But that is doomed to failure since it cannot work for NaN by its very definition. I think that just means the definition needs a bit more finesse. It would be a reasonable goal for it to give back *some* NaN with the same flags and payload as the original. -- Greg ___ 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/PDOKH6VHHU5QQYIN2BH2TDWJQ2WQRYF3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
Steven D'Aprano writes: > Since when did `from foo import *` suddenly become a widely adopted > coding practice? Right here, a few lines later in your same post: > Secondly, in practice people do their wildcard imports at the start > of the module, so they can make use of those names in their script or > application[.] Slow down, friend. You don't need to argue both sides of every issue. ___ 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/POCACSZIPPCRRXY7OBML2C2QCN6NAI5B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 5, 2020 at 7:26 PM Greg Ewing wrote: > On 6/09/20 8:08 am, David Mertz wrote: > > The only real goal I've seen is that you hope that `x == eval(repr(x))` > > for floating point numbers. But that is doomed to failure since it > > cannot work for NaN by its very definition. > > I think that just means the definition needs a bit more finesse. > It would be a reasonable goal for it to give back *some* NaN > with the same flags and payload as the original. > Sure, but we have that already: >>> from math import inf, nan >>> eval(repr([42, nan, inf])) [42, nan, inf] The only difference is the `math` namespace vs `builtins` namespace. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/HP5R24IXRL5LST3OQWWNNTALHLUCIVUN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
>>> inf =3
>>> eval(repr([1.0, 2.0, float('inf')]))
Obviously these are edge cases, and we could spent all day going over
particular cases which the repr -> eval identity doesn't hold. However I
still think that, as a principle, it's a solid one. I think changing the
repr of 'inf' to 'float('inf')' is a decent solution (but keeping str
conversion the same).
So, I guess in order to reduce backwards incompatibility, the repr could be
modified to return a string which actually generates an infinite value
On Sat, Sep 5, 2020, 8:14 PM David Mertz wrote:
> On Sat, Sep 5, 2020 at 7:26 PM Greg Ewing
> wrote:
>
>> On 6/09/20 8:08 am, David Mertz wrote:
>> > The only real goal I've seen is that you hope that `x == eval(repr(x))`
>> > for floating point numbers. But that is doomed to failure since it
>> > cannot work for NaN by its very definition.
>>
>> I think that just means the definition needs a bit more finesse.
>> It would be a reasonable goal for it to give back *some* NaN
>> with the same flags and payload as the original.
>>
>
> Sure, but we have that already:
>
> >>> from math import inf, nan
> >>> eval(repr([42, nan, inf]))
> [42, nan, inf]
>
> The only difference is the `math` namespace vs `builtins` namespace.
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born. Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/HP5R24IXRL5LST3OQWWNNTALHLUCIVUN/
> 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/2YJDNWCQCSREXVZWYDSIRO6L4ZJFYWJ3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 5, 2020 at 5:21 PM Cade Brown wrote:
> [...] we could spent all day going over particular cases which the repr ->
> eval identity doesn't hold. However I still think that, as a principle,
> it's a solid one. I think changing the repr of 'inf' to 'float('inf')' is a
> decent solution (but keeping str conversion the same).
>
> So, I guess in order to reduce backwards incompatibility, the repr could
> be modified to return a string which actually generates an infinite value
>
I would assume that there's a lot of code, much of it not written in
Python, that has been written to specifically look for this "inf" string.
So I don't think we should change it. And making the repr() of floats
different from their str() just in this one special case sounds like a bad
idea too.
I don't think we could fix this one without making 'inf' a builtin
constant, and I don't like that option at all. I also don't think this is
quite as big a deal as it seems to have become in your head. So please put
it to rest. There are many other worthy causes.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-ideas] Re: 'Infinity' constant in Python
Fair enough, I guess people have managed without it and there are plenty of
"good-enough" solutions for this that can be used in the place.
I can see it's probably not worth any code breakage for a more 'pure'
design that ultimately is more of an aesthetic problem than one which is
preventing real programs from being written
On Sat, Sep 5, 2020, 11:02 PM Guido van Rossum wrote:
> On Sat, Sep 5, 2020 at 5:21 PM Cade Brown wrote:
>
>> [...] we could spent all day going over particular cases which the repr
>> -> eval identity doesn't hold. However I still think that, as a principle,
>> it's a solid one. I think changing the repr of 'inf' to 'float('inf')' is a
>> decent solution (but keeping str conversion the same).
>>
>> So, I guess in order to reduce backwards incompatibility, the repr could
>> be modified to return a string which actually generates an infinite value
>>
>
> I would assume that there's a lot of code, much of it not written in
> Python, that has been written to specifically look for this "inf" string.
> So I don't think we should change it. And making the repr() of floats
> different from their str() just in this one special case sounds like a bad
> idea too.
>
> I don't think we could fix this one without making 'inf' a builtin
> constant, and I don't like that option at all. I also don't think this is
> quite as big a deal as it seems to have become in your head. So please put
> it to rest. There are many other worthy causes.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
