[Python-Dev] TypeError messages

Nick Coghlan ncoghlan at gmail.com
Sat Feb 21 15:26:23 CET 2015


On 21 February 2015 at 00:05, Brett Cannon <brett at python.org> wrote:
>
>
> On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka at gmail.com>
> wrote:
>>
>> Different patterns for TypeError messages are used in the stdlib:
>>
>>      expected X, Y found
>>      expected X, found Y
>>      expected X, but Y found
>>      expected X instance, Y found
>>      X expected, not Y
>>      expect X, not Y
>>      need X, Y found
>>      X is required, not Y
>>      Z must be X, not Y
>>      Z should be X, not Y
>>
>> and more.
>>
>> What the pattern is most preferable?
>
>
> My preference is for "expected X, but found Y".

Likewise, although as Rob noted, it's sometimes to desirable to use
the "Z should be X, not Y" form if the shorter form would be
ambiguous.

Perhaps this should be a recommendation in both PEP 7 & 8? It's
exactly the kind of issue where having a recommended way to do it can
save a fair bit of time considering the exact phrasing of error
messages, as well as improving the developer experience by providing
more consistent feedback on error details.

>> Some messages use the article before X or Y. Should the article be used
>> or omitted?
>>
>> Some messages (only in C) truncate actual type name (%.50s, %.80s,
>> %.200s, %.500s). Should type name be truncated at all and for how limit?
>
> I assume this is over some worry of string size blowing out memory
> allocation or something? If someone can show that's an actual worry then
> fine, otherwise I say don't truncate.

This is C, assuming strings are correctly NULL terminated is almost
always a recipe for future disaster :)

>> Type names newer truncated in TypeError messages raised in Python code.

Assuming the "newer" was intended to be "never", yes, that's due to
the main concern being with not blowing up in the face of missing
terminating NULLs in purported C strings. That concern doesn't exist
at the Python level.

>> Some messages enclose actual type name with single quotes ('%s',
>> '%.200s'). Should type name be quoted? It is uncommon if type name
>> contains spaces.
>
>  I agree that type names don't need to be quoted.

As a user, I actually appreciate the quotes, because they make the
error pattern easier for me to parse. Compare:

    int expected, but found str
    float expected, but found int

    'int' expected, but found 'str'
    'float' expected, but found 'int'

The variable information in this pattern (i.e. the types) gets
highlighted visually in the second version, as it's in the sections
surrounded by single quotes. For me, that helps the structural
scaffolding (the "expected, but found" part) to fade more readily into
the background as a familiar piece of text that primes my pattern
recognition, but doesn't change much across different error messages.

Regards,
Nick.

>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>



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


More information about the Python-Dev mailing list