[Paul Moore email@example.com]
... Can you share a bit more about why you need to do this? In the abstract, having the ability to split numbers over lines seems harmless and occasionally useful, but conversely it's not at all obvious why anyone would be doing this in real life.
It's not all that uncommon among people who work in algorithmic number theory.
The P in Steven's example is taken from a paper, where it's the _input_ to a short calculation that computes Q, a number with about 3 times as many digits. It's Q that's interesting, not really P. By careful construction, Q is a composite number that fooled many "prime testing" functions in many popular packages. They claimed Q is prime(*).
Where did P come from? It's complicated. Far easier to copy/paste than to compute (for Q, the opposite).
Which, as computational resources grow more capable, becomes more common: interesting results can be "big" indeed, but computing them _can_ require CPU-centuries of effort.
That said, while I enjoy playing in that area, I don't have a real problem with pasting such things in. They're too big to get any intuitive concept of their size by eyeball, so it's fine by me to leave them on a single line. Steven's "has 131 digits" comment is far more informative to me than any way of breaking the literal across multiple lines.
So I'm -0 on complicating syntax to cater to this. The int(implicitly pasted string literals) trick has been good enough for me when I've really wanted it.
(*) For those who care,
Q = P * (313*(P-1) + 1) * (353*(P-1) + 1)
Q is a "Carmichael number", a Fermat pseudoprime to all bases relatively prime to Q. It's also a strong pseudoprime to all bases < 307, meaning that all Miller-Rabin primality testers that stick to bases < 307 falsely claim it's prime. And P is Q's smallest prime factor, so "small to large" trial division is also hopeless for discovering that Q is composite. Ditto "large to small" trial division, since Q has no factors anywhere near its square root.