TypeError messages
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? 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? Type names newer truncated in TypeError messages raised in Python code. Some messages enclose actual type name with single quotes ('%s', '%.200s'). Should type name be quoted? It is uncommon if type name contains spaces.
On 2015-02-19 22:50, 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?
Stylistically, if the first part is in the active voice, then the second part should also be in the active voice: expected X, but found Y The active voice tends to be simpler and easier to parse than the passive voice. I think that the word "but" adds clarity here. Strictly speaking, that message is OK only if it's expecting X itself; if, in fact, it's expecting an instance of X, then you should really be saying something along the lines of: expected X instance, but found Y instance or: expected instance of X, but found instance of Y
Some messages use the article before X or Y. Should the article be used or omitted?
Messages tend not to be complete sentences anyway, so I think that it would be fitting to omit articles.
Some messages (only in C) truncate actual type name (%.50s, %.80s, %.200s, %.500s). Should type name be truncated at all and for how limit? Type names newer truncated in TypeError messages raised in Python code.
Truncating type names is probably not a good idea.
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 think that it should be quoted only if it's expecting those characters, e.g. if it's expecting a closing parenthesis, then it should say ')'. If, on the other hand, it's expecting a certain type, then it should give that type unquoted.
On 19/02/2015 23:57, MRAB wrote:
On 2015-02-19 22:50, 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?
Stylistically, if the first part is in the active voice, then the second part should also be in the active voice:
expected X, but found Y
The active voice tends to be simpler and easier to parse than the passive voice.
I think that the word "but" adds clarity here.
Strictly speaking, that message is OK only if it's expecting X itself; if, in fact, it's expecting an instance of X, then you should really be saying something along the lines of:
expected X instance, but found Y instance
or:
expected instance of X, but found instance of Y To me that is a purist argument, but in practice expected int, but found tuple is perfectly clear (I have received such messages myself!), and extra verbiage is just clutter. Identifying Z may be helpful however, so my feeling would be to stick to 2 patterns - the one above and Z should be int, not tuple (You may prefer e.g. "got" to "found", or "must" to "should". But ideally the usage should be the same throughout.) Rob Cliffe
Some messages use the article before X or Y. Should the article be used or omitted?
Messages tend not to be complete sentences anyway, so I think that it would be fitting to omit articles.
Some messages (only in C) truncate actual type name (%.50s, %.80s, %.200s, %.500s). Should type name be truncated at all and for how limit? Type names newer truncated in TypeError messages raised in Python code.
Truncating type names is probably not a good idea.
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 think that it should be quoted only if it's expecting those characters, e.g. if it's expecting a closing parenthesis, then it should say ')'. If, on the other hand, it's expecting a certain type, then it should give that type unquoted. _______________________________________________ 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/rob.cliffe%40btinternet.c...
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4800 / Virus Database: 4257/9145 - Release Date: 02/19/15
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
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.
Type names newer truncated in TypeError messages raised in Python code.
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.
On Fri Feb 20 2015 at 10:27:35 AM Stefan Richthofer < Stefan.Richthofer@gmx.de> wrote:
Honestly, the right solution would be to have a function or macro that generates the TypeError messages from X, Y, Z arguments. (Until now I actually believed this would be already the case) - type errors would be of uniform style - if for some reoson the format should be changed, this can be done in one central place - if someone would want to parse the error message this would be feasible I suppose it should be straight forward to find error message creations in the source by searching for "TypeError" or something. Maybe this kind of cleanup could be done along with the implementation of PEP 484?
Actually PEP 473 covers standardizing error messages by introducing keyword-only arguments which would lead to a standardized message being generated. From the C side there can be a function provided to make it easy to get the same result as constructing the exception with the keyword-only argument. -Brett
-Stefan
*Gesendet:* Freitag, 20. Februar 2015 um 15:05 Uhr *Von:* "Brett Cannon" <brett@python.org> *An:* "Serhiy Storchaka" <storchaka@gmail.com>, python-dev@python.org *Betreff:* Re: [Python-Dev] TypeError messages
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
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.
Type names newer truncated in TypeError messages raised in Python code.
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. _______________________________________________ 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/stefan.richthofer%40gmx.d... _______________________________________________ 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/ brett%40python.org
On 02/20/2015 09:05 AM, Brett Cannon wrote:
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.
I asked about this years ago, and was told it was in case the type name pointer was bad, and to limit the amount of garbage printed. Whether that's an actual problem or not, I can't say. It seems more likely that you'd get a segfault, but maybe if it was pointing to reused memory it could be useful. Eric.
IIRC there's a limited buffer used for the formatting. Also, if a dynamically created type name is 1000000 characters long I'd rather see it truncated than blow up my shell window. On Friday, February 20, 2015, Eric V. Smith <eric@trueblade.com> wrote:
On 02/20/2015 09:05 AM, Brett Cannon wrote:
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.
I asked about this years ago, and was told it was in case the type name pointer was bad, and to limit the amount of garbage printed. Whether that's an actual problem or not, I can't say. It seems more likely that you'd get a segfault, but maybe if it was pointing to reused memory it could be useful.
Eric.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <javascript:;> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (on iPad)
On 20.02.15 18:11, Eric V. Smith wrote:
I asked about this years ago, and was told it was in case the type name pointer was bad, and to limit the amount of garbage printed. Whether that's an actual problem or not, I can't say. It seems more likely that you'd get a segfault, but maybe if it was pointing to reused memory it could be useful.
Thank you. This makes sense and explains why type names are not truncated in Python code.
On 21 February 2015 at 00:05, Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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@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
On 21.02.15 16:26, Nick Coghlan wrote:
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.
Z is not always available.
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.
It would be great. I'm going to change standard messages in PyArg_Parse* and common converting functions (as PyLong_AsLong and PyObject_GetBuffer) to make them uniform.
On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 February 2015 at 00:05, Brett Cannon <brett@python.org> wrote:
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'
It's not a big deal to me either way, but I find the version with the quotes makes me think it is looking for the literal string 'int', but found the literal string 'str', whereas in the first case it seems clear it is looking for objects of that type. Perhaps this is just because I am used to the existing messages, but I think it goes beyond that. --David
On Sat, 21 Feb 2015 10:57:49 -0500 "R. David Murray" <rdmurray@bitdance.com> wrote:
On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 February 2015 at 00:05, Brett Cannon <brett@python.org> wrote:
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'
It's not a big deal to me either way, but I find the version with the quotes makes me think it is looking for the literal string 'int', but found the literal string 'str', whereas in the first case it seems clear it is looking for objects of that type. Perhaps this is just because I am used to the existing messages, but I think it goes beyond that.
Agreed. Regards Antoine.
On 21/02/2015 15:57, R. David Murray wrote:
On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 February 2015 at 00:05, Brett Cannon <brett@python.org> wrote:
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' It's not a big deal to me either way, but I find the version with the quotes makes me think it is looking for the literal string 'int', but found the literal string 'str', whereas in the first case it seems clear it is looking for objects of that type. Perhaps this is just because I am used to the existing messages, but I think it goes beyond that.
+1. FWIW, I feel the same as David (and Antoine). Rob Cliffe
Le 21 févr. 2015 15:27, "Nick Coghlan" <ncoghlan@gmail.com> a écrit :
int expected, but found str float expected, but found int
'int' expected, but found 'str' 'float' expected, but found 'int'
I would prefer quotes with the word type: 'float' type expected, but got 'int' type Or no quotes. Victor
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument. So it should be "expected X, but got Y". Personally, I think the "but" is superfluous: the contradiction is already implied, so "expected X, got Y" is terser and conveys the meaning just as well. Regards Antoine.
On Sat Feb 21 2015 at 12:15:25 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument.
So it should be "expected X, but got Y".
Personally, I think the "but" is superfluous: the contradiction is already implied, so "expected X, got Y" is terser and conveys the meaning just as well.
I'm also fine with the terser version. -Brett
On 2015-02-21 17:14, Antoine Pitrou wrote:
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument.
Well, it depends on the reason for the message. If you're passing an argument, then 'found' is the wrong word, but if you're parsing, say, a regex, then 'got' is the wrong word.
So it should be "expected X, but got Y".
Personally, I think the "but" is superfluous: the contradiction is already implied, so "expected X, got Y" is terser and conveys the meaning just as well.
If you wanted a message to cover both argument-passing and parsing, then "expected Y, not Y" would do.
On Sat, 21 Feb 2015 21:39:32 +0000 MRAB <python@mrabarnett.plus.com> wrote:
On 2015-02-21 17:14, Antoine Pitrou wrote:
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument.
Well, it depends on the reason for the message.
If you're passing an argument, then 'found' is the wrong word, but if you're parsing, say, a regex, then 'got' is the wrong word.
I don't think parsing would raise a TypeError, would it? Regards Antoine.
On 21/02/2015 21:39, MRAB wrote:
On 2015-02-21 17:14, Antoine Pitrou wrote:
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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".
If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument.
Well, it depends on the reason for the message.
If you're passing an argument, then 'found' is the wrong word, but if you're parsing, say, a regex, then 'got' is the wrong word.
So it should be "expected X, but got Y".
Personally, I think the "but" is superfluous: the contradiction is already implied, so "expected X, got Y" is terser and conveys the meaning just as well.
If you wanted a message to cover both argument-passing and parsing, then "expected Y, not Y" would do. Assuming you meant "expected Y, not X": +1 Perhaps better than all other suggestions so far.
On 21/02/2015 17:14, Antoine Pitrou wrote:
On Fri, 20 Feb 2015 14:05:11 +0000 Brett Cannon <brett@python.org> wrote:
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka <storchaka@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". If we are busy nitpicking, why are we saying "found Y"? Nothing was *found* by the callee, it just *got* an argument.
So it should be "expected X, but got Y".
Personally, I think the "but" is superfluous: the contradiction is already implied, so "expected X, got Y" is terser and conveys the meaning just as well.
Regards
Antoine. +1 Rob Cliffe
participants (12)
-
Antoine Pitrou -
Brett Cannon -
Eric V. Smith -
Guido van Rossum -
MRAB -
Nick Coghlan -
R. David Murray -
Rob Cliffe -
Serhiy Storchaka -
Stefan Behnel -
Stefan Richthofer -
Victor Stinner