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

[Nick Coghlan]

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".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia