You might be interested in https://pypi.org/project/extended-int/
Fair enough, I guess people have managed without it and there are plenty of "good-enough" solutions for this that can be used in the place.I can see it's probably not worth any code breakage for a more 'pure' design that ultimately is more of an aesthetic problem than one which is preventing real programs from being writtenOn Sat, Sep 5, 2020, 11:02 PM Guido van Rossum <gu...@python.org> wrote:--On Sat, Sep 5, 2020 at 5:21 PM Cade Brown <brown...@gmail.com> wrote:[...] we could spent all day going over particular cases which the repr -> eval identity doesn't hold. However I still think that, as a principle, it's a solid one. I think changing the repr of 'inf' to 'float('inf')' is a decent solution (but keeping str conversion the same).So, I guess in order to reduce backwards incompatibility, the repr could be modified to return a string which actually generates an infinite valueI would assume that there's a lot of code, much of it not written in Python, that has been written to specifically look for this "inf" string. So I don't think we should change it. And making the repr() of floats different from their str() just in this one special case sounds like a bad idea too.I don't think we could fix this one without making 'inf' a builtin constant, and I don't like that option at all. I also don't think this is quite as big a deal as it seems to have become in your head. So please put it to rest. There are many other worthy causes.--Guido van Rossum (python.org/~guido)Pronouns: he/him (why is my pronoun here?)