Thanks everyone for your comments. Replying to everyone (so far) at once. Chris Angelico: I would be okay with your suggestion that line-breaking the int requires parentheses: a = 123_ # remains a SyntaxError b = (123_ 456) # legal but I don't know how easy that is for the parser. Paul Moore:
But I would ask, do you *really* type numbers like that in manually???
Alas, sometimes the only source I have for the number is a PDF of a scanned paper (pixels, not copyable text) so yes, it has happened a few times that I have had to manually retype the number. But the motivation for this is not to reduce the amount of typing, but to make the number nicer to read. It's about presentation. For example, here's the source of the number P I gave earlier: https://www.sciencedirect.com/science/article/pii/S0747717185710425?via%3Dih... and P is given on page 7 (as p1), split over two lines. Even if I could copy and paste it, I would still have to edit it back to a single line. Using underscores to group digits doesn't reduce the length of the number, it makes it longer :-) For smaller numbers, in the trillions say, breaking the number up into triplets is helpful: a = 478_190_347_801 but with 100+ digit numbers I don't find that helpful. Although now you mention it I might separate the number into groups of ten or twenty. But I would still like to split it over multiple lines. Christopher Barker:
This seems like a pretty uncommon use case. But are there applications to other contexts where we might want easy line continuation?
Sure, using huge ints is rather uncommon. Are there other use-cases for breaking huge ints over multiple lines that don't involve huge ints? Probably not :-) I'm not proposing trailing underscore as a general line continuation mechanism. We already have two of those: - explicit line continuation with a trailing backslash; - implicit line continuation inside open brackets; but neither can be used to split a 100+ digit integer in the middle of the constant. So this proposal is specific to huge ints. Mike Miller: I'm not sure what benefit you gain from moving the constant into an ini file. Moving it into an ini file just adds distance between the code and the value it needs to run, and adds a dependency that must be met or the code can't run. You need extra function calls to open the file, read the value as a string, and convert to an int. By default, ints in ini files can't be split over multiple lines, so you haven't actually solved the problem. And worst of all, the value isn't a config setting that the end user can configure. Putting it into an ini file is an invitation to "tweak" the constant, but that's just going to break things. -- Steven