[issue26512] Vocabulary: Using "integral" in library/stdtypes.html

[Julien]

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 <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________