[Python-Dev] How far to go with user-friendliness
tjreedy at udel.edu
Tue Jul 14 20:11:37 CEST 2015
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
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
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
2. It gives the impression that 'assret' is a legitimate alias for
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
More information about the Python-Dev