[Python-ideas] Re: 'Infinity' constant in Python
On Tue, Sep 8, 2020 at 3:42 PM Christopher Barker wrote:
>> On versions starting with that one, you MUST NOT have that line,
>> as it would be a SyntaxError.
>
> Huh? I was proposing doing it like was done for True and False in Python 2:
They were just builtins, not keywords at all.
> but True and False are still "special" at least with ast.literal_eval:
>
> In [8]: ast.literal_eval("[True, False]")
> Out[8]: [True, False]
>
> I fully agree that this "tiny benefit" is not worth breaking a lot (or hardly
> any) code. But it seems it can be done with very little breakage.
Yes - literal_eval in Python 2.7 had a whitelist of valid names.
Exactly like I'd been suggesting earlier. :) If you want "inf" to be
special, write your own literal_eval that treats it as special. It's
really not hard. CPython is open source, and the ast module is written
in Python, so you can just go look at how it works :)
ChrisA
___
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/SGOX2VVYI4YTPNNSHWRBXBOAO3OYQJ3R/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
> > That is, if you removed:
>
> > from math import inf
>
> > From your code, nothing would break.
>
>
> Everything would break. On versions prior to the one that introduced
> the new literal form, you MUST have that line, or your code won't
> work.
But it’s already there.
On versions starting with that one, you MUST NOT have that line,
> as it would be a SyntaxError.
Huh? I was proposing doing it like was done for True and False in Python 2:
(python 2.7)
In [1]: from bools import True, False
In [7]: print True, False
1 0
but True and False are still "special" at least with ast.literal_eval:
In [8]: ast.literal_eval("[True, False]")
Out[8]: [True, False]
I fully agree that this "tiny benefit" is not worth breaking a lot (or
hardly any) code. But it seems it can be done with very little breakage.
In fact, this is even less likely to break code than the introduction of
True and False were, 'cause math,inf and numpy,inf actually do return a
float with the value of inf - the very same type and value that this would
produce. And frankly, it would get used a LOT less than True and False are
as well.
-CHB
___
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/UWAJRRKG53IVERAQYX4CAZ7APIRNEBT2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Tue, Sep 8, 2020 at 9:21 AM Christopher Barker wrote: > I’m actually liking this more as I think about it. And it seems it wouldn’t > actually break any code that currently defines those names. And in many > cases, it would do the same thing as those names currently do, if a bit > differently. > > That is, if you removed: > > from math import inf > > From your code, nothing would break. Everything would break. On versions prior to the one that introduced the new literal form, you MUST have that line, or your code won't work. On versions starting with that one, you MUST NOT have that line, as it would be a SyntaxError. That's an awful lot of breakage for such a tiny benefit. ChrisA ___ 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/OJZ7ZPISU42KGBFAS2RIHENQ5MYEM45Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
> But then you might as > > > well make it a built-in name, which would behave almost exactly > > > the same way, and Guido doesn't want to do that. Do you have a reference for that preference? And Guido is no longer the > BDFL, though of course, very well respected opinion. and you'll see that the magic constants (eg True) have an AST node of > > type "Constant", as do literals that represent constants. That sounds like the “right” thing to do with this, if anything. similar to name lookups than to constants, and it'd definitely need > > special handling inside literal_eval. Which is why just adding these to the builtin names doesn’t quite do it. > it'd be way WAY cleaner to > > just build a function similar to literal_eval that permits exactly the > > operations you're okay with. Sure, that would be the way to make a “PYSON” reader like I would like, but that’s not really the goal of this proposal, such as it is — making “inf” work with literal_eval is not so much the goal, as a shorthand for what I guess is: Make “inf” and “nan” Constants. The idea is that, if the names have not been defined in that scope, they would behave like any other literal everywhere in Python. I’m actually liking this more as I think about it. And it seems it wouldn’t actually break any code that currently defines those names. And in many cases, it would do the same thing as those names currently do, if a bit differently. That is, if you removed: from math import inf >From your code, nothing would break. I honestly don’t think I want this enough to try to push it through, but it’s a +1 >From me, for what that’s worth (two cents, maybe? ) -CHB > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/K67TGF3TQZV6SATQUAPN2YNUBQNXWSP3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] wrapping up 4 years of open source python > 12 pep ideas
Dear python enthusiasts, --(you can skip this part if you're in a hurry)-- 4 years ago I was discovering this great language. Already an experienced software developer and data scientist at that time, accustomed with both low-level (C++), Object-Oriented (Java), Query (T-SQL), and Script (MATLAB) languages, I still have to admit that I was blown away by the capabilities and expressiveness of python ! Our team leveraged python during this period to develop our second cloud-based Analytics as a Service platform. As I found out, even if the quantity of available open source python libraries was already huge, many elements were missing in order to cover all of our needs in an elegant, "pythonic" way. So I first developed some common libraries for internal use, and eventually made some of them open source to make them more mature and to get community feedback. At first it was difficult to create elegant libs, but after a dozen I think that I began to "get it right". Now that we are reaching the 4th year anniversary (and I am about to take some rest for a second paternity leave), I thought that it would be a great time to do a summary of the main issues that I came across with python, and share this with you. Most of these issues were so blocking/frustrating that I had to create a library to fix them, when I could. Still, I believe that some deserve a better fix, directly in the core python stdlib or, for one or two of them maybe, in the language itself. --- The result is a list of 12 PEP topics/ideas that can be found and discussed here: https://github.com/smarie/python-pep-ideas/issues . For reference, the list of open source libraries that were at the origin of the discovery or the fix of these issues is here: https://github.com/smarie/ALL_OF_THE_ABOVE#overview . I tried to use git labels to relate ideas with their related lib. I hope that this will serve the python community and maybe make python even greater in the future! Kind regards - stay safe -- Sylvain ___ 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/T3DSXIKWX64HFMEVAYVBQ7NKOPYWW2QF/ Code of Conduct: http://python.org/psf/codeofconduct/
