Re: [Python-Dev] TypeError messages
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.
___
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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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.com
-
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
___
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/archive%40mail-archive.com
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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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?
-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 <storch...@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.de
___
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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On Fri Feb 20 2015 at 10:27:35 AM Stefan Richthofer <
stefan.richtho...@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.de
> ___
> 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
>
___
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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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 https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
IIRC there's a limited buffer used for the formatting. Also, if a dynamically created type name is 100 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 > 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) ___ 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/archive%40mail-archive.com
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 | ncogh...@gmail.com | Brisbane, Australia
___
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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
Serhiy Storchaka schrieb am 21.02.2015 um 16:35: > I'm going to change standard messages in PyArg_Parse* > and common converting functions (as PyLong_AsLong and PyObject_GetBuffer) > to make them uniform. *sigh* - and along came another heap of doctest adaptations... Stefan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On Fri, 20 Feb 2015 14:05:11 + 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. 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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On Sat Feb 21 2015 at 12:15:25 PM Antoine Pitrou wrote: > On Fri, 20 Feb 2015 14:05:11 + > 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. > > 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On 2015-02-21 17:14, Antoine Pitrou wrote: On Fri, 20 Feb 2015 14:05:11 + 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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On Sat, 21 Feb 2015 21:39:32 + MRAB wrote: > On 2015-02-21 17:14, Antoine Pitrou wrote: > > On Fri, 20 Feb 2015 14:05:11 + > > 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. I don't think parsing would raise a TypeError, would it? Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On 21/02/2015 17:14, Antoine Pitrou wrote: On Fri, 20 Feb 2015 14:05:11 + 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. 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
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 + 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. ___ 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/archive%40mail-archive.com
