There's a reason why adding this to int feels right to me. In mypy we treat int as a sub*type* of float, even though technically it isn't a sub*class*. The absence of an is_integer() method on int means that this code has a bug that mypy doesn't catch:
def f(x: float): if x.is_integer(): "do something" else: "do something else" f(12) This passes the type check (because 12 is considered an acceptable substitute for float) but currently fails at runtime (because x is an int and does not have that method). You may think that mypy is obviously wrong here, but in fact we (the Python community) have gone through considerable hoops to make other cases like this work at runtime (e.g. adding .imag and .real to int), and disallowing ints where a float is expected in mypy would cause unacceptable noise about many valid programs (the difference in runtime behavior between int and float was much more pronounced in Python 2, where integer division truncated, and we intentionally changed that for the same reason). So I think the OP of the bug has a valid point, 27 years without this feature notwithstanding. And while mypy does not endorse or use the numeric tower, given the strong argument for adding the method to int, it makes sense to add it to all types in the numeric tower as well. I have no strong opinion about what to do for Decimal, which in general doesn't like to play nice with other ABCs (in general I think Decimal is doing itself a disfavor by favoring the language-independent Decimal standard over Python conventions, but that's a discussion for another time). On Mon, Mar 12, 2018 at 11:10 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 12 Mar 2018 09:49:27 -0700 > Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > > > > Starting point: Do we need this? > > * We already have a simple, traditional, portable, and readable way to > make the test: int(x) == x > > It doesn't look that obvious to me. As a reviewer I would request to > add a comment explaining the test. > > > * Aside from the OP, this behavior has never been requested in Python's > 27 year history. > > That's possible. One thing I often see is suboptimal compatibility > with third-party integer types such as Numpy ints, but that's a > slightly different request (as it usually doesn't imply accepting > Numpy floats that exactly represent integrals). > > > Does it cost us anything? > > * Yes, adding a method to the numeric tower makes it a requirement for > every class that ever has or ever will register or inherit from the tower > ABCs. > > Well, the big question is whether the notion of numeric tower is useful > in Python at all. If it's useful then there's a point to expand its > usability with such a feature. Personally I don't care much :-) > > > As a result, we ended-up with an awkward and error-prone API that > requires double parenthesis for the valid use case: url.endswith(('.html', > '.css')). > > It doesn't look that awkward to me. > > Regards > > Antoine. > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com