Ordinal number in identifier classified as typo

[foriequal0]

#410 seems to fix only 2nd__ or __3rd at the identifier tokenizer level.
Variable names such as level_2nd are split as ["level", "2", "nd"] by the SplitIdent.
I think I can fix it by marking words whether they might be ordinal suffixes or not and then using a different dictionary according to that.

[epage]

So far we've focused our ordinal handling on english, which extended to markdown support. We have not tried to handle ordinals within variable names.

Doing this would require special casing our case splitter for ordinals. I'm a bit mixed on the value of this; personally I've rarely seen ordinals in variable names and would probably discourage it if I saw it in a review, independent of typos behavior.

[neiljp]

From #681, in my case these are not variable names, but rather test-case id strings which are being formatted in a snake-case-like way (partly since pytest uses - as a test-case id-separator).

I agree that with variable names I would recommend expanding them if I saw them as one-offs, and if multiple may query their presence.

However, here these are test case names, and eg. 1st/2nd/3rd is more concise and easier to read than first/second/third due to the digits present.

[epage]

FYI #695 provides a new workaround for false positives