Julien added the comment:
Hi Martin, awesome work you've done here. I was meditating those past days
about the subject and came to a similar yet not that good conclusion that the
table should have the same definitions than those from
[library/math.html](https://docs.python.org/3.5/library/math.html#number-theoretic-and-representation-functions).
But your solution is better, copy-paste is wrong, let's just link to the right
documentation, in which case, a simple list is enough, there is no need for a
table.
The definitions in the *library/math.html* and *library/functions.html* (for
round) are perfectly clear and understandable, and properly link to
number.Integral each time it's used. For the record:
math.trunc(x)
Return the Real value x truncated to an Integral (usually an integer).
Delegates to x.__trunc__().
math.ceil(x)
Return the ceiling of x, the smallest integer greater than or equal to x.
If x is not a float, delegates to x.__ceil__(), which should return an Integral
value.
math.floor(x)
Return the floor of x, the largest integer less than or equal to x. If x is
not a float, delegates to x.__floor__(), which should return an Integral value.
round(number[, ndigits])
Return the floating point value number rounded to ndigits digits after the
decimal point. If ndigits is omitted, it returns the nearest integer to its
input. Delegates to number.__round__(ndigits).
For the built-in types supporting round(), values are rounded to the
closest multiple of 10 to the power minus ndigits; if two multiples are equally
close, rounding is done toward the even choice (so, for example, both
round(0.5) and round(-0.5) are 0, and round(1.5) is 2). The return value is an
integer if called with one argument, otherwise of the same type as number.
Note The behavior of round() for floats can be surprising: for example,
round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug:
it’s a result of the fact that most decimal fractions can’t be represented
exactly as a float. See Floating Point Arithmetic: Issues and Limitations for
more information.
About the docstrings not being the same as the documentation, is there a "best
practice" on how it should be ? Should'nt them always be the same ?
Here's a first patch to replace the table with a simple list.
----------
keywords: +patch
Added file: http://bugs.python.org/file42144/stdtypes.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
