Just FYI and as further motivation, I reimplemented this dedicated parser for quicktions (in Cython, so the timings and speedups are not comparable).

https://github.com/scoder/quicktions/commit/cc034e07325ec492decdb7b1bcca69246cc780fd

I was able to get another quite visible improvement by caching the values of "10 ** shift" for 0 <= shift < 58 in a tuple. Higher values are very unlikely in practice, and the memory size of a tuple with 58 values gives a nice multiple of the usual cache line size. (I originally stored 64 values in my commit but then cut it down later.)

https://github.com/scoder/quicktions/commit/c20add53dc4936d70eb0daa370946a600adddca9

I suspect that the difference won't be as big for the Python implementation, but it still seems worth a try.

The overall speedup that I got, compared to the initial regex implementation, is 50-70%.

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")'
200000 loops, best of 5: 1.19 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")'
500000 loops, best of 5: 593 nsec per loop

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")'
100000 loops, best of 5: 2.3 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")'
500000 loops, best of 5: 667 nsec per loop

It could be even higher if I additionally moved the int() integer parsing into Cython. Might try that at some point. But that's also not something that concerns the implementation in CPython.