Re: [Python-Dev] TypeError messages

On 21 February 2015 at 00:05, Brett Cannon wrote:

On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka 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@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@gmail.com | Brisbane, Australia