Could you also add a test case for Fraction('232e\t2') (this should fail).

Done.

The new code is not very easy to read, but neither is the regular expression that is currently in main.

I think that the later is more clear. Also, it has more nice tracebacks.

So, I'm still not sure about this. Speed gain is x2 at most. Maybe regexps can be eventually optimized?

I was surprised that manual parsing is faster than a regexp-based approach. The regular expression is not optimal, so I tried to optimize it, but the benefit was minuscule. The regexp engine needs to be optimized.

Can we please wait a few months with these changes while I try to optimize the regexp engine for such case? This seems so typical that a lot of code would benefit from optimization.

I was surprised that manual parsing is faster than a regexp-based approach.

But not too much.

The regexp engine needs to be optimized.
Can we please wait a few months with these changes while I try to optimize the regexp engine for such case?

Sure. I'm not familiar with the regexp module code and I would be interested in such fix, if it's possible at all. BTW, so far this pr was not approved by core dev.

@serhiy-storchaka, but what about other change, i.e. moving down numbers.Rational check? Maybe I should factor out this to a separate pr? See benchmarks (third column) andmy arguments for this.

Ok, now this has only optimization for str inputs. Other goes to#134320