Thomas Fischbacher added the comment:
Re AlexWaygood:
If these PEP-484 related things were so obvious that they would admit a compact
description of the problem in 2-3 lines, these issues would likely have been
identified much earlier. We would not be seeing them now, given that Python
Thomas Fischbacher added the comment:
Tim, the problem may well be simply due to the documentation of math.isfinite()
being off here.
This is what we currently have:
https://docs.python.org/3/library/math.html#math.isfinite
===
math.isfinite(x)
Return True if x is neither an infinity nor
Thomas Fischbacher added the comment:
This is not a partial duplicate of https://bugs.python.org/issue47121 about
math.isfinite().
The problem there is about a specific function on which the documentation may
be off -
I'll comment separately on that.
The problem here
New submission from Thomas Fischbacher :
Here is a major general problem with python-static-typing as it is
described by PEP-484: The approach described in
https://peps.python.org/pep-0484/#the-numeric-tower negatively impacts
our ability to reason about the behavior of code with stringency.
I
Thomas Fischbacher added the comment:
The problem with PEP-484 is that if one wants to use static type analysis,
neither of these options are good:
- Use static annotations on functions, and additionally spec
out expectations in docstrings. Do note that the two types places
where "
New submission from Thomas Fischbacher :
>>> help(math.isfinite)
isfinite(x, /)
Return True if x is neither an infinity nor a NaN, and False otherwise.
So, one would expect the following expression to return `True` or `False`. We
instead observe:
>>> math.isfinite(1
Thomas Fischbacher added the comment:
Addendum
Serhiy, I agree that my assessment was incorrect.
It actually is unittest/mock.py that has quite a few 'raise AssertionError'
that are not coming from an 'assert' keyword statement.
At a deeper level, the problem here is as follows:
Every
Thomas Fischbacher added the comment:
The documentation of exceptions in the reference is one of the places that
makes the life of users substantially harder than it ought to be, since the
documentation appears to not have been written with the intent to give
guarantees that users can
New submission from Thomas Fischbacher :
The Python reference says:
(1) https://docs.python.org/3/library/exceptions.html#concrete-exceptions
exception AssertionError
Raised when an assert statement fails.
(2) https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement
Thomas Fischbacher added the comment:
The current behavior deviates from the documentation in a way that might evade
tests and hence has the potential to cause production outages.
Is there a way to fix the documentation so that it correctly describes current
behavior - without having
New submission from Thomas Fischbacher :
This problem may also be the issue underlying some other dataclasses.asdict()
bugs:
https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid=fi
11 matches
Mail list logo
