> the first thing it sees looks like the start of a number
Yes, because it checks if the token is a number before checking if it is a name.
But to know if a token is a name, it has to check, and that check never happens because the tokenizer yields when the number case hits. You can attach a debugger and see for yourself.
> It doesn't matter in which order the rules are checked.
Nowhere did I claim otherwise. The rules _do_ happen in a deterministic order, which I posted the source code for.
> Nowhere did I claim otherwise.
You claimed otherwise when you wrote "Because the hexadecimal parsing rule [0] happens before [1] the rule that parses names [2]", and when you wrote "literals have to be evaluated before names", and when you wrote "the rules can’t be evaluated concurrently". That is, you claimed otherwise in every single one of your posts in this subthread.
You are conflating the fact that there is an order to the rules with a strawman that the rules _must_ be evaluated in a specific order. All of the quotes you pulled are facts (Python checks if a token is a number before it checks if it is a name, Python checks if a token is a literal before it checks if it is a name, and the rules are not evaluated concurrently), but your strawman is making a different claim.
I'm not the one who wrote "literals have to be evaluated before names".
> rules are not evaluated concurrently
Strawman yourself. I didn't say they were evaluated concurrently, I said that your claim that they can't be evaluated concurrently was wrong. They could be, because they are disjoint, and regardless of order only one of them can match at input starting with a '0' character.
Anyway, I'm done here.