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 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".

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" *An:* "Serhiy Storchaka" , python-dev@python.org *Betreff:* Re: [Python-Dev] TypeError messages

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".

...

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

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 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 01:57, MRAB wrote:

Messages tend not to be complete sentences anyway, so I think that it would be fitting to omit articles.

Thanks. This post was aroused by your note about articles on the tracker.

On 21.02.15 10:03, Guido van Rossum wrote:

IIRC there's a limited buffer used for the formatting.

For now formatting buffer is not limited. But other arguments are valid.

On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote:

On 21 February 2015 at 00:05, Brett Cannon 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" wrote:

On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote:

...

On 21 February 2015 at 00:05, Brett Cannon 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.

Le 21 févr. 2015 15:27, "Nick Coghlan" 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 2015-02-21 17:14, Antoine Pitrou wrote:

On Fri, 20 Feb 2015 14:05:11 +0000 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".

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 21/02/2015 15:57, R. David Murray wrote:

On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote:

...

On 21 February 2015 at 00:05, Brett Cannon 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

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 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".

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.