t, 13 Feb 2021 16:25:24 -0500
> Cade Brown wrote:
>
> > In my humble opinion, arrows should be '->' instead of '=>'. It always
> > annoys me when languages use that symbol
>
> That's unlikely, as was discussed in this thread previously:
>
>
In my humble opinion, arrows should be '->' instead of '=>'. It always
annoys me when languages use that symbol
On Sat, Feb 13, 2021, 14:52 Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 13 Feb 2021 09:24:51 -0800
> Matthias Bussonnier wrote:
>
> > Works well with 0 parameters and currying, read a
You should really just write your own function -- Python can't include
every validation function you can think of. It already provides an
extensible and well tested float conversion which throws an exception on
bad input (the 'float' constructor)
You want it to not throw an exception, but rather r
```
import myfile
```
or
```
from myfile import *
```
Will import the names from another file. You should use this instead of
executing text read from a path.
Thanks,
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College
I have also thought it would be nice to have a 'prev()' method to
compliment 'next()'
On Wed, Oct 7, 2020, 3:24 PM Wes Turner wrote:
> __setstate__, a generic __getstate__, listiter.__setstate__, (typed)
> arrays and memoryviews
>
> ```python
> import collections.abc
> from array import array
>
;>> 1 / 0
>>> 1 / 0.0
inf
This would also be very unexpected
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu
On Tue, Sep 15, 2020 at 7:02 AM Paul Moore wrote:
> On Tue,
To me it seems like a useful shortcut that means:
>>> x == True and type(x) == bool
But, as you say, it is best to just let the Python interpreter treat it as
a boolean (i.e. within an `if`, it is converted automatically)
Now, I am thinking it would actually be *bad* to have the CPython
impleme
ng a float from C, check if it is infinite, and if so,
return a new reference to the global inf/-inf variable).
Again, this is not part of the PEP, so I don't think we want to spend much
time discussing whether they should be singletons. For now, the answer
seems to be: no
Thanks,
*
inf' and 'nan' to
builtin names (like True and False). If that happened, a 'nan' singleton
wouldn't make sense unless you had 2**53 of them, so code like:
>>> x is nan
Would be a flawed formulation
Thanks,
*Cade Brown*
Research Assistant @ ICL (Innovative
As per tagged nans, check for JavaScript tagged NaN optimization.
Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
pointer. Obviously, this is a very advanced use case, probably not worth
Python guaranteeing such behavior.
Here is one article:
https://brionv.com/log/2018/05/1
If, in the future, Python used a library such as MPFR and made all floats a
given precision (say, by giving a flag to the interpreter "python
-prec2048"), it would never be enough to make infinity because it only has
the limitation of a 64 bit exponent.
This is just an example of course, probably
This syntax seems ugly to me, clunky, and as you said probably breaks
existing code
This, to me, is less clear than current methods of generating an 'inf'
which is the whole reason I proposed it
Thanks,
----
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Pers
on-1 email
conversations, or should it be kept in the public mailing list?
Thanks,
----
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email: brown.c...@gmail.com
ICL/College Email: c...@utk.edu
On Tue, Sep 8, 2020 at 11:48 PM Guido van Rossum wrote:
> If
n 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'
>>> 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'
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 Br
nstead 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
similar to 'Infinity' constants (some differences: `float('nan')
is float('nan')` is False, whereas `NaN is NaN` would be True, but of
course `NaN == NaN` is still False)
Thanks,
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email:
mplete, predictable and
frankly 'prettier' language (albeit subjective). I don't see how any of
your points address those concerns
On Fri, Sep 4, 2020, 10:14 PM Steven D'Aprano wrote:
> On Fri, Sep 04, 2020 at 09:40:55PM -0400, Cade Brown wrote:
> > The `eval(repr(x
#x27;d like to not focus on arguing whether a particular codebase
should be using 'eval' on strings generated by repr.
Rather, my point was that the current behavior does not follow what Python
suggests and says 'repr' should do.
*Cade Brown*
Research Assistant @ ICL (Innovative
n
>
> 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]: False
>
> -CHB
>
>
>
> On Fri, Sep 4, 2020
essly 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
- Converting a float to string is not the same as it is in C. Whil
I also realize that there is `math.inf`, but I argue th
When I quoted 10% as a rough measurement I was referring more to set
operations like union, etc, which choosing the larger set may have a very
real performance advantage.
For membership tests which are false, it may be quicker, as less memory is
accessed. The buckets will be smaller (1,2,4, or 8
push back on the idea that ordered-by-insertion sets are not
more memory efficient -- they can use the same optimizations that
ordered-by-insertion dictionaries are currently using (albeit with tighter
margins, since only 2 words are saved per empty bucket instead of 3, as
with dictionaries)
y
belief (and I'm sure many others share this as well) that
unspecified/implementation-dependent/otherwise-undependable features should
be eliminated and replaced with exact semantics that do not suprise users.
Thoughts?
Thanks,
~
Cade Brown
Working on MAGMA <https://icl.cs.utk.ed
25 matches
Mail list logo
