[Python-ideas] Re: 'Infinity' constant in Python

[David Mertz]

Thanks so much Ben for documenting all these examples. I've been frustrated
by the inconsistencies, but hasn't realized all of those you note.

It would be a breaking change, but I'd really vastly prefer if almost all
of those OverflowErrors and others were simply infinities. That's much
closer to the spirit of IEEE-754.

The tricky case is 1./0. Division is such an ordinary operation, and it's
so easy to get zero in a variable accidentally. That one still feels like
an exception, but yes 1/1e-323 vs. 1/1e-324 would them remain a sore spot.

Likewise, a bunch of operations really should be NaN that are exceptions
now.

On Mon, Sep 14, 2020, 5:26 PM Ben Rudiak-Gould  wrote:

> On Mon, Sep 14, 2020 at 9:36 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> Christopher Barker writes:
>>  > IEEE 754 is a very practical standard -- it was well designed, and is
>>  > widely used and successful. It is not perfect, and in certain use
>> cases, it
>>  > may not be the best choice. But it's a really good idea to keep to that
>>  > standard by default.
>>
>
> I feel the same way; I really wish Python was better about following IEEE
> 754.
>
> I agree, but Python doesn't.  It raises on some infs (generally
>> speaking, true infinities), and returns inf on others (generally
>> speaking, overflows).
>>
>
> It seems to be very inconsistent. From testing just now:
>
> * math.lgamma(0) raises "ValueError: math domain error"
>
> * math.exp(1000) raises "OverflowError: math range error"
>
> * math.e ** 1000 raises "OverflowError: (34, 'Result too large')"
>
> * (math.e ** 500) * (math.e ** 500) returns inf
>
> * sum([1e308, 1e308]) returns inf
>
> * math.fsum([1e308, 1e308]) raises "OverflowError: intermediate overflow
> in fsum"
>
> * math.fsum([1e308, inf, 1e308]) returns inf
>
> * math.fsum([inf, 1e308, 1e308]) raises "OverflowError: intermediate
> overflow in fsum"
>
> * float('1e999') returns inf
>
> * float.fromhex('1p1024') raises "OverflowError: hexadecimal value too
> large to represent as a float"
>
> I get the impression that little planning has gone into this. There's no
> consistency in the OverflowError messages. 1./0. raises ZeroDivisionError
> which isn't a subclass of OverflowError. lgamma(0) raises a ValueError,
> which isn't even a subclass of ArithmeticError. The function has a pole at
> 0 with a well-defined two-sided limit of +inf. If it isn't going to return
> +inf then it ought to raise ZeroDivisionError, which should obviously be a
> subclass of OverflowError.
>
> Because of the inconsistent handling of overflow, many functions aren't
> even monotonic. exp(2*x) returns a float for x <= 709.782712893384, raises
> OverflowError for 709.782712893384 < x <= 8.98846567431158e+307, and
> returns a float for x > 8.98846567431158e+307.
>
> 1./0. is not a true infinity. It's the reciprocal of a number that may
> have underflowed to zero. It's totally inconsistent to return inf for
> 1/1e-323 and raise an exception for 1/1e-324, as Python does.
>
> ___
> 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/TXEZTNVIKJFEGPH535KYZ4B5KVNNGBZZ/
> 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/GLUX5WVRF3VBJTD3EBH5MCSRWBASJZOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Joao S. O. Bueno]

On Fri, 11 Sep 2020 at 19:50, David Mertz  wrote:

> I like the idea of having these functions, but I don't like overloading
> the argument to a function with "filename or file-like object" as is common
> in libraries like Pandas.  I think there are a few places the standard
> library does it, but the separation seems better to me.
>
> I don't LOVE the names dumpf() and loadf(), but I don't have an obviously
> better choice.  I guess probably I'd want fromfile() and tofile() as more
> "modern" names.
>

While separating the methods to avoid method overloading feels much cleaner
(and I also think of it that way), w have to look at the
other side of it:
If .load and .dump are super-charged, people coding with these methods in
mind have _one_ less_  thing to worry about:
if the method accepts a path or an open file becomes irrelevant. On th othr
hand, with two extra methods,
anyone coding the samething have one _extra_ thing to worry about, even
more things than they have today!
Nowadays, one learn that 'ok, so load takes an open file", and that's it.
With two new methods it becomes
"ok, was it dump or dumpf which took an openfile? Or was it the other way
around?" - and that is bad.

Parameter overloading has been around from O.O. inception, it is used in
other parts of Python, and
permissive signatures are part of what made Python so atractive along the
years.

So, this is "the other side".


>
> On Fri, Sep 11, 2020 at 12:17 PM Christopher Barker 
> wrote:
>
>> I"m pretty sure this came up recently, and was pretty much rejected.
>>
>> Another option would be to have json.dump take a file-like-object or a
>> path-like object -- there's plenty of code out there that does that.
>>
>> hmm.. maybe that was the version that was rejected.
>>
>> But I like the idea either way. it always seemed cumbersome to me to
>> write the whole context manager in these kinds of cases.
>>
>> -CHB
>>
>>
>>
>>
>>
>> On Fri, Sep 11, 2020 at 2:05 PM The Nomadic Coder <
>> atemysemico...@gmail.com> wrote:
>>
>>> Personally prefer it to be in the json module as it just feels more
>>> logical. But that's just a personal choice.
>>>
>>> I didn't mention about dumpf as I see a previous thread that became
>>> quite controversial (seems like dumps was a more common usage at that time).
>>>
>>> Something I forgot to mention : A (non-exact)search for this construct
>>> in github (https://github.com/search?q=with+open+%3A+json.load&type=Code)
>>> gives 20million+ results. Seems like it's a popular set of statements that
>>> people use ...
>>>
>>> 
>>> The Nomadic Coder
>>> ___
>>> 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/R4CZ2IGLXR5NYNQDDFZZE5YB3RHD3RP6/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> 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/4XVZAXRXQKZKTJJAH4WHXFVQGA57YFAV/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> 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/WOTLFRSGGRGVIYEIOCTGQJAWA2KK5PPJ/
> 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/EQGT5IESXX265YBI5YA4IYVL5A7ARSRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Ben Rudiak-Gould]

On Mon, Sep 14, 2020 at 9:36 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Christopher Barker writes:
>  > IEEE 754 is a very practical standard -- it was well designed, and is
>  > widely used and successful. It is not perfect, and in certain use
> cases, it
>  > may not be the best choice. But it's a really good idea to keep to that
>  > standard by default.
>

I feel the same way; I really wish Python was better about following IEEE
754.

I agree, but Python doesn't.  It raises on some infs (generally
> speaking, true infinities), and returns inf on others (generally
> speaking, overflows).
>

It seems to be very inconsistent. From testing just now:

* math.lgamma(0) raises "ValueError: math domain error"

* math.exp(1000) raises "OverflowError: math range error"

* math.e ** 1000 raises "OverflowError: (34, 'Result too large')"

* (math.e ** 500) * (math.e ** 500) returns inf

* sum([1e308, 1e308]) returns inf

* math.fsum([1e308, 1e308]) raises "OverflowError: intermediate overflow in
fsum"

* math.fsum([1e308, inf, 1e308]) returns inf

* math.fsum([inf, 1e308, 1e308]) raises "OverflowError: intermediate
overflow in fsum"

* float('1e999') returns inf

* float.fromhex('1p1024') raises "OverflowError: hexadecimal value too
large to represent as a float"

I get the impression that little planning has gone into this. There's no
consistency in the OverflowError messages. 1./0. raises ZeroDivisionError
which isn't a subclass of OverflowError. lgamma(0) raises a ValueError,
which isn't even a subclass of ArithmeticError. The function has a pole at
0 with a well-defined two-sided limit of +inf. If it isn't going to return
+inf then it ought to raise ZeroDivisionError, which should obviously be a
subclass of OverflowError.

Because of the inconsistent handling of overflow, many functions aren't
even monotonic. exp(2*x) returns a float for x <= 709.782712893384, raises
OverflowError for 709.782712893384 < x <= 8.98846567431158e+307, and
returns a float for x > 8.98846567431158e+307.

1./0. is not a true infinity. It's the reciprocal of a number that may have
underflowed to zero. It's totally inconsistent to return inf for 1/1e-323
and raise an exception for 1/1e-324, as Python does.
___
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/TXEZTNVIKJFEGPH535KYZ4B5KVNNGBZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom keywords (from: Decorators for class non function properties)

[Marco Sulla]

Little errata: change

Cython, for example, uses its parser to compile Python code

to

Cython, for example, uses its parser to compile Cython code
___
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/5JOT2U52QBWMUQQEPQB42ABARNLNVYNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom keywords (from: Decorators for class non function properties)

[Marco Sulla]

On Sun, 23 Aug 2020 at 02:42, Guido van Rossum  wrote:
> IMO this is just too large of a step to expect either redradrist or Marco 
> Sulla to take.

You're quite right, I have proposed it to have an opinion by experts.
Indeed I have no knowledge about how a parser works. This is why I
asked if this is possible and desirable.
Anyway, I was not thinking about a macro system, but about custom
keywords. Maybe a macro is more simple, but was not my idea.
My idea is to be able to delegate the parsing of a piece of code to a
custom parser, defined in a third-party module.

Cython, for example, uses its parser to compile Python code to C code.
Cython uses custom keywords like cdef to speed up the code introducing
C static typing.

My idea and question is if it's possible to have something like this:


from cython import *

@int a = 0


About Jython and other implementations, as far as I know they can't
use C extensions. Not without many troubles.
___
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/75N4W2NQMC3LZOPY5TU7357D5YYZO3D3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Serhiy Storchaka]

14.09.20 19:55, Chris Angelico пише:
> I think not; unless there are API details to be hashed out or
> counterarguments to be rebuffed, I think this is fairly simple and
> non-controversial.

I also considered this issue simple and non-controversial. But the
discussion turned in an unexpected direction.

> (If someone disagrees with me, then it's clearly at least somewhat
> controversial, and I withdraw the above.)
> 
> Can you create a PR directly? If not, create a bugs.python.org issue
> to track it. Either way, it's up to the core devs to decide, but it
> shouldn't need all the overhead of a full PEP.

And don't forget to update also modules marshal, pickle and plistlib.
___
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/M3MRFM5UD7U3JNLJOOS35S5H25KIZDOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Marco Sulla]

I just had an idea: we have mp->ma_used and keys->dk_nentries.

holes = mp->ma_keys->dk_nentries - mp->ma_used

is the number of holes in the dict.
So, if holes == 0, you have O(1). But, if the dict has holes, you
can't have O(1), but you can speedup the check of the entry by
counting the NULLs in the for loop. When the number of NULLs reaches
holes, you can jump safely to the dict entry you need.

In this case, O(n) can happen only if the items are removed from the
end, as with popitem().
___
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/G4VO262RMJALR35G74B72PFCTXT524LQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Marco Sulla]

Well, I didn't read the entire discussion... but I wrote in
unsuspicious times a stupid little module, msutils, with two stupid
little functions, jsonLoad and jsonDump:

https://github.com/Marco-Sulla/msutils/blob/master/msutils/jsonutil.py#L20
___
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/SDILJ67J5HF5P5SLR4WXYXGQGI2ACCUS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

[Marco Sulla]

@Inada (senpai?):

In the meanwhile I tried to apply some tricks to speedup the dict
creation without success.
This is my effort:
https://github.com/Marco-Sulla/cpython/blob/master/Objects/dictobject.c

As you can see, I simply "cloned" some functions that create dict, and
removed some checks that are not needed at creation:

1. the "override" flag
2. the check for resizing, since in theory I would do one big resize
at start (but I have some problems, see below)
3. the introduction of an "empty" parameter, that is false only if you
have to insert key-value pairs AND you also have a positional
parameter
4. some random const, when the code permits it
5. changing of ma_used, ma_version_tag, dk_usable, dk_nentries only
one time, after the for loop that insert all the items
6. some little shortcut (for example, PyDictKeysObject *keys =
mp->ma_keys; and using keys in the rest of the code)
7. changing some checks in asserts
8. calling directly the internal static functions

I tested it with a dict with an "hole", since I noticed that you
already improved the creation of dict when the source it's another
dict and it's "perfect".
The speedup is a mere 2.5%...

Furthermore, I failed to do one big resize with dict. I was ok with
frozendict because I always used dicts or seq2 as parameters. But
defaultdict passes a class as first argument. So PyObject_Length fails
miserably, and I had to remove the resize. Anyway, I didn't
reintroduce the resize, so in theory the code should be faster (even
if one odict test fails, of course).

Some questions:

1. How can we check the size of an object only if it's an iterable
using the Python C API?
2. Why, in your opinion, no relevant speedup was done?

PS: My next and final try is to improve the speed of lookups, the only
other field where frozendict is faster. I hope to have better luck
here.
___
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/CVJWH4CFUA3RDKDPY74LQXFKN6NZS4B5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Guido van Rossum]

On Mon, Sep 14, 2020 at 9:58 AM Chris Angelico  wrote:

> On Tue, Sep 15, 2020 at 2:41 AM Christopher Barker 
> wrote:
> >
> > There seems to be a fair bit of support for this idea.
> >
> > Will it need a PEP ?
>
> I think not; unless there are API details to be hashed out or
> counterarguments to be rebuffed, I think this is fairly simple and
> non-controversial.
>

I agree.


> (If someone disagrees with me, then it's clearly at least somewhat
> controversial, and I withdraw the above.)
>
> Can you create a PR directly? If not, create a bugs.python.org issue
> to track it. Either way, it's up to the core devs to decide, but it
> shouldn't need all the overhead of a full PEP.
>

It will still need a bpo issue, so might as well create one now.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/YMA5WL6A4QAHVDZKNEBON3MUD7WFJP7E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Christopher Barker]

On Mon, Sep 14, 2020 at 10:00 AM Chris Angelico  wrote:

> On Tue, Sep 15, 2020 at 2:41 AM Christopher Barker 
> wrote:
> >
> > There seems to be a fair bit of support for this idea.
> >
> > Will it need a PEP ?
>


> I think not; unless there are API details to be hashed out or
> counterarguments to be rebuffed, I think this is fairly simple and
> non-controversial.
>

agreed -- at least the simple part. The only API detail I"ve seen is
whether to make json.load() take a "path-like or file-like" object, or to
have separate functions. And I think the consensus is to have separate
functions. And to name them ``loadf()`` and ``savef``.

The other potential API issue is whether to support arbitrary encdoings --
but I think the consensus there is also no.

So yes -- pretty simple.

> Can you create a PR directly? If not, create a bugs.python.org issue

> to track it.


not me -- I'm having enough trouble finding time to srite the inf/nan PEP.
But I think the OP offered to do so.


> Either way, it's up to the core devs to decide, but it
> shouldn't need all the overhead of a full PEP.
>

And if it does, the core devs can tell us then.

-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/C7BHVT5K2SWVSXJIC2VESALYHHGBQX7A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Chris Angelico]

On Tue, Sep 15, 2020 at 3:45 AM Richard Damon  wrote:
>
> On 9/14/20 12:34 PM, Stephen J. Turnbull wrote:
> > That's fine, but Python doesn't give you that.  In floats, 0.0 is not
> > true 0, it's the set of all underflow results plus true 0.  So by your
> > argument, in float arithmetic, we should not have ZeroDivisionErrors.
> > But we do raise them.
>
> Actually, with IEEE, 0.0 should be all numbers, when rounded to the
> nearest representation give the value 0.
>
> When we get to very small numbers, the 'sub-normals', we get numbers
> that are really some integral value times 2 to some negative power (I
> think it is something like 2 to the -1022 for the standard 64 bit
> floats). This says that as we approach 0, we have  sequence of evenly
> spaced representable values, 3*2**-1022, 2*2**-1022, 1*2**-1022, 0*2**-1022
>
> Thus the concept of "Zero" makes sense as the nearest representable value.
>
>
> Now, as been mentioned, "Infinity", doesn't match this concept, unless
> you do something like define it as it represents a value just above the
> highest represntable value, but that doesn't match the name.
>

In mathematics, "infinity" isn't a value. One cannot actually perform
arithmetic on it. But in mathematics, it's perfectly acceptable to
talk about stupid big numbers and do arithmetic that wouldn't ever be
possible with full precision (eg calculating the last digits of
Graham's Number). Mathematicians are also perfectly happy to work with
transcendental numbers as actual values, and, again, to perform
arithmetic on them even though we don't know the exact value.

Computers can't do that. So we have a set of rules for approximating
mathematics in ways that are useful, even though they're not true
representations of real numbers. (Something something "practicality
beats purity" yada yada.) That's why we have to deal with rounding
errors, that's why we have to work with trig functions that aren't
perfectly precise, etc, etc. They're *good enough* for real-world
usage. And that's why we need "Infinity" to be a value, of sorts. If
you wish, every IEEE float can be taken to represent a range of values
(all those that would round to it), but that's not often useful
(although AIUI that's how Python chooses to give a shorter display for
many numbers - it finds some short number that would have the same
representation and prints that). Much more practical to treat them as
actual numbers, including that 0.0 really does mean the additive
identity (and is the sole representation of it), even though this
leads to contradictions of sorts:

x = 1.0
x != 0.0 # True
y = float(1<<53)
x + y == y # True
# Subtract y from both sides, proving 1.0 == 0.0

If you want to define infinity as any particular value, you're going
to get into a contradiction somewhere sooner or later. But its
behaviour in IEEE arithmetic is well defined and *useful* even without
trying to make everything make sense.

Let's stick to discussing whether "inf" (or "Infinity") should become
a new builtin name, and let the IEEE experts figure out whether
infinity is a thing or not :)

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/GKULPWOYKSM4HWE6UUTNA4LSU32DASKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Richard Damon]

On 9/14/20 12:34 PM, Stephen J. Turnbull wrote:
> That's fine, but Python doesn't give you that.  In floats, 0.0 is not
> true 0, it's the set of all underflow results plus true 0.  So by your
> argument, in float arithmetic, we should not have ZeroDivisionErrors.
> But we do raise them.

Actually, with IEEE, 0.0 should be all numbers, when rounded to the
nearest representation give the value 0.

When we get to very small numbers, the 'sub-normals', we get numbers
that are really some integral value times 2 to some negative power (I
think it is something like 2 to the -1022 for the standard 64 bit
floats). This says that as we approach 0, we have  sequence of evenly
spaced representable values, 3*2**-1022, 2*2**-1022, 1*2**-1022, 0*2**-1022

Thus the concept of "Zero" makes sense as the nearest representable value.


Now, as been mentioned, "Infinity", doesn't match this concept, unless
you do something like define it as it represents a value just above the
highest represntable value, but that doesn't match the name.

-- 
Richard Damon
___
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/LDQKH6J2GISGQ26TVWZQJNJE5S2TBV3Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Chris Angelico]

On Tue, Sep 15, 2020 at 2:41 AM Christopher Barker  wrote:
>
> There seems to be a fair bit of support for this idea.
>
> Will it need a PEP ?
>

I think not; unless there are API details to be hashed out or
counterarguments to be rebuffed, I think this is fairly simple and
non-controversial.

(If someone disagrees with me, then it's clearly at least somewhat
controversial, and I withdraw the above.)

Can you create a PR directly? If not, create a bugs.python.org issue
to track it. Either way, it's up to the core devs to decide, but it
shouldn't need all the overhead of a full PEP.

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/IIIHV3KZEMOZGGG7RC4TXNDIJ6VTRFUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Christopher Barker]

There seems to be a fair bit of support for this idea.

Will it need a PEP ?

-CHB

On Mon, Sep 14, 2020 at 9:20 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Christopher Barker writes:
>
>  > On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull <
>
>  > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>  >
>
>  > >  > encoding=None: this is the important one -- json is always UTF-8
> yes?
>
>  > >
>
>  > > Standard JSON is always UTF-8.  Nevertheless, I'm quite sure that
>
>  > > there's a ton of Japanese in Shift JIS, including some produced by
>
>  > > default in Python on Windows.  I'll bet the same is true of GBK for
>
>  > > Chinese, and maybe even ISO-8859-1 in Europe.
>
>  >
>
>  > So what should the json lib do with these?
>
>
>
> Well, I'm a mail guy from way back, so I'm with Mr. Postol: be
>
> libertine in what you accept, puritan in what you emit.  I think given
>
> the current architecture of json, dump and load are fine as is, dump
>
> should be discourage (but not removed!) in favor of dumpf, and dumpf
>
> and loadf should provide no option but UTF-8.
>
>
>
> I just wanted to point out that it's very likely that there's a lot of
>
> "JSON-like" data out there, and probably a lot of "unwritten
>
> protocols" that expect it.  While nobody has proposed removing dump
>
> and load, I don't want them deprecated or discouraged for the purpose
>
> of dealing with "JSON-like" data, especially not load.
>
>
>
>
>
> --
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/2GBNGQAK5WD5WJR7IDD77IFVV3VRXC6M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Stephen J. Turnbull]

Christopher Barker writes:
 > On Sun, Sep 13, 2020 at 8:10 AM Stephen J. Turnbull <
 > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
 > 
 > > As Steven points out, it's an overflow, and IEEE *but not Python* is
 > > clear about that.  In fact, none of the actual infinities I've tried
 > > (1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of inf.  The
 > > former raises ZeroDivisionError and the latter gives the finite value
 > > 1.633123935319537e+16.
 > 
 > probably because math.pi is not exact, either -- I'm pretty sure Python is
 > wrapping the C lib for math.tan, so that's not a Python issue.

The issue is that Python doesn't produce true infinities as far as I
know, so "inf" is a very poor name for float('inf') in builtins.  I
wince at math.inf as well, but at least there it feels like "this is
an IEEE 754 feature that Python uses".

 > In the Python world, numpy lets the user control the error
 > handling:

Not every 1_000_000 line module needs to be a builtin.  We're talking
about adding these names to the builtins, what NumPy does is
irrelevant (and NumPy already has its own inf).

 > As you've noticed, Python itself has limited use for Inf and NaN values,
 > which is probably why it got as far as it did with the really bad support
 > before 2.6. But these special values are used in external code called from
 > Python (including numpy), an so it's helpful to have good support for them
 > in Python anyway.

What's ungood about "from math import inf, nan"?
Or "from numpy import inf, nan"?

 > IEEE 754 is a very practical standard -- it was well designed, and is
 > widely used and successful. It is not perfect, and in certain use cases, it
 > may not be the best choice. But it's a really good idea to keep to that
 > standard by default.

I agree, but Python doesn't.  It raises on some infs (generally
speaking, true infinities), and returns inf on others (generally
speaking, overflows).  To change that you need to bring in C
extensions.

 > Note that one of the key things about numpy, and why its defaults are
 > different, is that it does array-oriented math. Most people do not want
 > their entire computation to be stopped if only one value in an array under-
 > or over-flows, etc.

That's fine, but Python doesn't give you that.  In floats, 0.0 is not
true 0, it's the set of all underflow results plus true 0.  So by your
argument, in float arithmetic, we should not have ZeroDivisionErrors.
But we do raise them.

 > Anyway, the only  thing on the table now is putting a couple names in the
 > builtin namespace.

Which is why I've tried pretty hard to stick to those aspects of inf
and nan that are builtin to Python or available directly with "from
math import inf, 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/2DZLX5WARQVNNQT4MIANSN4IFDULOQJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

[Stephen J. Turnbull]

Christopher Barker writes:
 > On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull <
 > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
 > 
 > >  > encoding=None: this is the important one -- json is always UTF-8 yes?
 > >
 > > Standard JSON is always UTF-8.  Nevertheless, I'm quite sure that
 > > there's a ton of Japanese in Shift JIS, including some produced by
 > > default in Python on Windows.  I'll bet the same is true of GBK for
 > > Chinese, and maybe even ISO-8859-1 in Europe.
 > 
 > So what should the json lib do with these?

Well, I'm a mail guy from way back, so I'm with Mr. Postol: be
libertine in what you accept, puritan in what you emit.  I think given
the current architecture of json, dump and load are fine as is, dump
should be discourage (but not removed!) in favor of dumpf, and dumpf
and loadf should provide no option but UTF-8.

I just wanted to point out that it's very likely that there's a lot of
"JSON-like" data out there, and probably a lot of "unwritten
protocols" that expect it.  While nobody has proposed removing dump
and load, I don't want them deprecated or discouraged for the purpose
of dealing with "JSON-like" data, especially not load.

___
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/T53PT6HLPRM3ZMWYM7AZEBEITXKFGKRA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Cade Brown]

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
implementation define `inf` singletons -- imagine a 3rd party library (for
example, sympy) that defines '==' for new types:

```
>>> from sympy import oo
>>> oo == inf
True
>>> oo is inf
False
```
Again, it would be useful for a shortcut: `x is inf` is the same as `x ==
inf and type(x) == float`, but with 3rd party libraries I don't think it's
something good to rely on.



On Mon, Sep 14, 2020, 12:05 AM Steven D'Aprano  wrote:

> On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:
>
> > (How often do people even use "x is True"?)
>
> Alas, that is a common idiom. For example:
>
>
> https://stackoverflow.com/questions/50816182/pep-8-comparison-to-true-should-be-if-cond-is-true-or-if-cond
>
> It's possibly less common than it used to be now that PEP 8 warns
> against it:
>
> https://www.python.org/dev/peps/pep-0008/
>
> and so linters flag it. But I've seen it used by beginners and
> experienced programmers alike.
>
> There is some justification for it in the case that you want to test
> specifically for the True instance, being much shorter than:
>
> arbitrary_object == 1 and type(arbitrary_object) is bool
>
> but many people have a mental blindspot and write:
>
>
> if flag is True:
> true_condition()
> else:
> false_condition()
>
>
> even when they know full well that flag is guaranteed to be a bool.
>
> I know that sometimes I catch myself doing the same. I recently
> rediscovered some old Pascal code I write in the 1990s and sure enough,
> I have "if flag == true" in that too.
>
> Of course we all know that it should be written:
>
> if flag is True is True:
> ...
>
> except I never know when to stop:
>
> if flag is True is True is True is True is True is True is ...
>
>
> *wink*
>
>
> --
> 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/45KTF4Z6EMXLSLN5PFXKS4QGIM3QEKGR/
> 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/3IX5OHELMZPGIYEOLTAW3P47NABXAOQG/
Code of Conduct: http://python.org/psf/codeofconduct/