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
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 (
>>> 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'
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
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 th
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 wou
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 re
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 co
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 wrot
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
> 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
refe
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
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
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 symb
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,
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_e
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 c
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 maili
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 alon
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 constan
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 unsubs
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 tel
22 matches
Mail list logo
