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%3Dihub
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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/DUCCSPELJLFP4R2FITDFY6U2227CVTBH/
Code of Conduct: http://python.org/psf/codeofconduct/
