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

[Terry Reedy]

On 7/14/2015 8:39 AM, Nick Coghlan 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?

> Drawing the line at only rejecting "assert_" *would* have been a
> reasonable alternative design choice, but it isn't the one Kushal and
> Michael made, and there isn't a compelling argument in favour of
> changing the implementation of the new guard to allow the typo'ed
> prefix.

I strongly disagree that there is no compelling argument for reversal. 
Part of the reason for beta is so we have time to evaluate whether an 
enhancement is even a good idea. Many of us think special-casing 
'assret' is an awful one. This idea never got consensus or even majority 
approval.

1. It is false that 'assret' is necessarily a typo. Someone might quite 
legitimately use it as an attribute. Aside from the fact that it might 
be an *intentional* misspelling to avoid a clash with 'assert', I found 
the following on Google.
a. It appears to be both a (person) name (Turkey?) and a username.
b. It can be a contraction, abbreviation, or pair of acronym: ass-et 
ret-ention, ass-istant ret-ired (?), and something in connection with 
high-pressure oil lines.  Python usage is not restricted to 
English-speaking geeks.

2. It gives the impression that 'assret' is a legitimate alias for 
'assert'.  See 
https://stackoverflow.com/questions/31382895/any-core-real-reference-to-assret-as-alias-to-assert
This may have been what prompted Dima to go look on Google.

If the doc is revised to counter this impression, then I predict that 
this will join the list of Python warts and reasons to ridicule Python.

3. It violates Python design principles. To many, the beauty of Python 
is that it is relatively clean and simple, and not filled with hundreds 
of nitpicky exceptions and special cases.  Being BDFL for a module 
should not be a license to add junk like this.

-- 
Terry Jan Reedy