[Python-Dev] How far to go with user-friendliness

[MRAB]

On 2015-07-14 14:09, Nick Coghlan wrote:
> On 14 July 2015 at 22:53, Xavier Morel <python-dev at masklinn.net> wrote:
>>
>> On 2015-07-14, at 14:39 , Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
>>>> Thus the question, how far should Python go to detect possible
>>>> erroneous user behaviour?
>>>>
>>>> Granted it is in tests only, but why not detect assrte, sasert, saster
>>>> and assrat?
>>>
>>> Because "r" and "e" are right next to each other on a QWERTY keyboard
>>> (so it's an easy typo to make), and transposing them doesn't change
>>> the overall shape of the word (so it's a hard typo to detect).
>>
>>> If you get the "a" or "t" out of position you change the shape of the
>>> word so typos involving those are easier to detect visually, while "s"
>>> and "e" are on different keyboard rows so typos at that point in the
>>> word are less likely in the first place.
>>
>> "sasert" fits these rules though.
>
> That changes one of the end letters, and human word recognition is
> generally pretty good at picking up changes to the first and last
> letter. It's the ones in the middle that can be a problem, especially
> when they're all the same height like "sser". And that's with typical
> word recognition capabilities - my understanding is that for folks
> that actually have dyslexia, discrepancies in letter order are even
> harder to detect.
>
> Dima's right that the main defence against this kind of error is
> actually linters and IDEs, but detecting this particular one at
> runtime is harmless, so there's no particular reason *not* to do it
> when it's possible to construct a reasonable rationale for "Why this
> particular typo?" and not all the other possible ways of transposing
> adjacent letters in "assert".
>
What about "aasert"?