Yes, but that could also be said about ordinary global classes.
if sys.args[1] == "a":
class A:
pass
a = A()
print(pickle.dumps(a))
else:
a = pickle.loads(input()) # no definition of class A in this run
> I'm not sure that would work
On Fri, Sep 4, 2020 at 7:19 PM haael wrote:
>
> Yes, but that could also be said about ordinary global classes.
(Please don't top-post, it makes it very difficult to usefully quote
multiple people.)
>
> if sys.args[1] == "a":
> class A:
> pass
>
> a = A()
>
>
Dear list,
log records in the Python logging library always use timestamps provided
by `time.time()`, i.e. the usual system clock (UTC, CLOCK_REALTIME).
This time is used as absolute timestamp in log records and for
timestamps relative to the load of the library (Lib/logging/__init__.py:
`_startT
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
I mentioned that in my post; however it doesn't satisfy the problems I have
(mainly being that eval(repr(x))==x)
I still think unifying it as a constant is better because then the repr of
a float gives a string which, if evaluated, gives the float back exactly.
Using math.inf or string conversion
This is in the math module already, along with NaN:
In [1]: import math
In [2]: math.inf
Out[2]: inf
In [3]: math.nan
Out[3]: nan
The same value
In [4]: math.inf == float('inf')
Out[4]: True
but not the same object -- i.e. it's not a singleton.
In [5]: math.inf is float('inf')
Out[5]: F
On Sat, Sep 5, 2020 at 8:12 AM Cade Brown wrote:
>
> I mentioned that in my post; however it doesn't satisfy the problems I have
> (mainly being that eval(repr(x))==x)
>
> I still think unifying it as a constant is better because then the repr of a
> float gives a string which, if evaluated, giv
On Fri, Sep 4, 2020, 12:48 Cade Brown 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;
>
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.
On Sat, Sep 5, 2020 at 8:45 AM Greg Ewing wrote:
>
> 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
On Sat, Sep 5, 2020 at 12:43 AM Greg Ewing
wrote:
> 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
On Fri, 4 Sep 2020 at 19:12, Cade Brown wrote:
> I mentioned that in my post; however it doesn't satisfy the problems I
> have (mainly being that eval(repr(x))==x)
>
In [1]: from math import inf
In [2]: eval(repr(inf)) == inf
Out[2]: True
"works for me"
>
> I still think unifying it as a co
On Fri, Sep 04, 2020 at 06:10:23PM -0400, Cade Brown wrote:
> I mentioned that in my post; however it doesn't satisfy the problems I have
> (mainly being that eval(repr(x))==x)
I'm not very sympathetic to that problem. `eval(repr(x))` is a Nice To
Have convenience for the interactive interpreter,
On Fri, Sep 04, 2020 at 06:10:23PM -0400, Cade Brown wrote:
> I mentioned that in my post; however it doesn't satisfy the problems I have
> (mainly being that eval(repr(x))==x)
Further to my previous comment, if you *absolutely must* use eval, you
can mitigate some (but not all) security threats
On Sat, Sep 5, 2020 at 10:11 AM Steven D'Aprano wrote:
>
> On Fri, Sep 04, 2020 at 06:10:23PM -0400, Cade Brown wrote:
>
> > I mentioned that in my post; however it doesn't satisfy the problems I have
> > (mainly being that eval(repr(x))==x)
>
> Further to my previous comment, if you *absolutely m
On 5/09/20 10:51 am, Chris Angelico wrote:
If you make "inf" a keyword, then even the Python
standard library is broken.
The OP didn't suggest that, he suggested adding a new name
such as Infinity that reprs could use.
--
Greg
___
Python-ideas mailin
On Sat, Sep 5, 2020 at 11:30 AM Greg Ewing wrote:
>
> On 5/09/20 10:51 am, Chris Angelico wrote:
> > If you make "inf" a keyword, then even the Python
> > standard library is broken.
>
> The OP didn't suggest that, he suggested adding a new name
> such as Infinity that reprs could use.
>
Suggeste
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 o
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 type
"from foo import *" is a really lazy programming practice that assumes
there are no symbol clashes between the module's namespace and the
current namespace. It makes production code harder to maintain because
the reader has to figure out whether a given function or class name is
defined in the
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).
Which is a real, though maybe not important, use case.
-CHB
On Fri, Sep 4, 2020 at 7:15 PM Steven D'Aprano wrote:
> On Fri, Sep 04, 2020 at
On Fri, Sep 04, 2020 at 08:52:22PM -0700, Christopher Barker wrote:
> 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).
>
> Which is a real, though maybe not important, use case.
That's
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
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
On Sat, Sep 05, 2020 at 12:44:47AM -0400, Cade Brown 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, e
25 matches
Mail list logo
