make numeric literal juxtaposition less brittle

[StefanKarpinski]

The most obvious two changes would be:

• disallow 0 as a juxtaposed numeric literal coefficient: 0n would be a syntax error.
• disallow juxtaposition of floating-point numeric literals with trailing .: 1.x would be a syntax error.

There may be others but these two strike me as clearly a good idea. One nice thing about disallowing 0 as a juxtaposed numeric literal coefficient is that it opens up as many 0x1234 syntaxes as one might ever want, so it kind of future-proofs us for that. Another nice thing is that instead of getting a surprise when they try 0x after 0y just working, people will get a warning as soon as they try 0y and they can immediately learn that 0 doesn't work as a juxtaposed numeric literal coefficient.

[stevengj]

See also #5246, #11529, #10920, ... for related problems with literals and operators etc.

[StefanKarpinski]

I think I would generally be in favor of deprecating float literals with trailing . but that's another matter.

[StefanKarpinski]

This is a pretty simple change and we would benefit from doing it sooner rather than later.

[StefanKarpinski]

Bump – @JeffBezanson, could you do this?

[JeffBezanson]

Number parsing changes are never simple :)

Working on this. First interesting issue I hit is 0im, which seems useful to allow.

[StefanKarpinski]

Ah, that's an interesting one.

[omus]

Maybe a better option to disallowing 0n is to require 0x1234 syntaxes to use upper case letters. Then we could also support many 0x style syntaxes via r"0[a-z][A-Z0-9]+". This would mean that 0xa is 0*xa, 0xA is 0x0A, and 0im would still work.

[StefanKarpinski]

How about allowing 0x to mean 0*x and disallowing 0 juxtaposed with any starting with a single non-digit followed by a digit (and anything after that). That way 0x and 0im are allowed, and 0x1 would be a hex value while 0y1 would be illegal. It's slightly more brittle than I would like, but at least the rule doesn't care about a specific list of leading characters.