Title: What should the error message in the exception raised by assertTrue and assertFalse be?
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.9
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ammar2, brandtbucher, ezio.melotti, mark.dickinson, michael.foord, mkarotsieris, petr.viktorin, r.david.murray, rbcollins, serhiy.storchaka, steven.daprano, terry.reedy
Priority: normal Keywords: patch

Created on 2019-11-05 21:16 by mkarotsieris, last changed 2019-11-07 19:45 by serhiy.storchaka.

Pull Requests
URL Status Linked Edit
PR 17049 closed mkarotsieris, 2019-11-05 21:20
PR 17073 closed serhiy.storchaka, 2019-11-06 10:23
Messages (16)
msg356065 - (view) Author: Mikeli Karotsieri (mkarotsieris) * Date: 2019-11-05 21:16
The error messages included in the exceptions raised when assertTrue and assertFalse fail are respectively:  

'False is not true' 
'True is not false '

This issue's goal is to find out if it would be more correct or/and beneficial for those messages to be: 

'False is not True' 
'True is not False'

As a side note, the suggested error message is syntactically correct Python. 

The assosciated file is Lib/unittest/ .
msg356067 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-05 21:33
assertTrue() does not assert that the value is True. It asserts that it is true. For example, non-zero number or non-empty collections will pass the check.
msg356081 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2019-11-06 00:23
I'm reopening this as an enhancement, because I think Mikeli is onto something here. I'd like to propose making the messages:

    "False is not a truthy value."
    "True is not a falsey value."

to make it explicit that we are testing not for the singletons True and False by identity, but for any truthy or falsey value.

If you don't like the terms "truthy" and "falsey", lower-case true and false would also be acceptable.
msg356082 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2019-11-06 00:25
Since error messages aren't part of the API and backwards-compatibility doesn't apply to them, this could still go into 3.8.
msg356083 - (view) Author: Ammar Askar (ammar2) * (Python triager) Date: 2019-11-06 00:26
I like Steven's "truthy value" or "true value" proposal. Another alternative:

"x does not evaluate to true"
"x does not evaluate to false"
msg356103 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-06 08:07
I am not English expert, but traditionally "true" is used as a synonym of a truthy value everywhere in the Python documentation and code. There are almost 2000 occurrences. If it is a wrong word, it should be fixed in all these cases.
msg356104 - (view) Author: Ammar Askar (ammar2) * (Python triager) Date: 2019-11-06 08:11
I don't think the word "true" is really the issue here. It's the fact that "is" in this context is ambiguous, is it referring to the English "is" or the python operator `is`?
msg356105 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-06 08:15
There are almost 500 occurrences of "is true".
msg356114 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2019-11-06 10:41
I also feel that lower case true and false are synonymous with any truthy and falsey values, as I'm sure many others do, so things in this area should in general stay as they are. Certainly -1 for a search-and-replace approach!
msg356120 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-11-06 11:48
I pretty strongly dislike 'truthy' and 'falsey'.  They look slangy and gives the main meaning as 
  (US, colloquial) Only superficially true; ...

The computer language usage is credited to Javascript here and some other sites (with the same meaning as in Python).

To be a bit pedantic, the current failure message for assertTrue(x) appears to be f'{repr(x)} is not true'.

Exception messages are English phrases and sentences, not Python code, so 'is' in exception messages is always the English 'is', as in
  NameError: name 'true' is not defined
I do not see any ambiguity.  Somewhat ironically, the original suggestion 'False is not True', which should better be written '<x> is not True' *could* be misinterpreted as code.

'x does not evaluate to true' strikes me as wrong because in this context, the evaluation by calling bool(x) is to True or False, not 'true' or 'false'.

'assertTrue' is an abbreviation for something like 'assertBoolTrue(x)' or more properly, assert_bool(x)_is_True.  A correct failure message, correct both as English and Python, should be something like 'bool(x) is not True'.  I see 'x is not true' as an informal English equivalent of the full claim.  Perhaps this should be better explained somewhere in the doc.  I do not really see 'x is not a true value' as adding anything.

We don't usually change exception messages in bugfix releases unless the message is buggy, as in actively misleading.  I also think making a change would need discussion on pydev.
msg356124 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2019-11-06 12:47
I have tried sending this message by email twice, and both times it seems to have disappeared. So I'm commenting via the web, and my apologies in advance if the message shows up later.


> There are almost 500 occurrences of "is true".

We can worry about them if and when somebody raises them as a "bug
report" or feature request. Without reading each one in context, I have
no idea whether they are good, bad or indifferent. Doing a massive
search and replace would be a bad idea.

Right now we have a simple feature request: improve the assertTrue and
assertFalse messages. There is a simple way to improve them. We don't
have to touch any other message, just these two.

Personally, I prefer "truthy and falsey" or "true-like and false-like"
over "true and false" to distinguish between "duck-typed bools" and the
actual bool singletons True and False. But I don't prefer them enough to
fight over the terms. If you prefer "true and false", that's okay with
me too :-)

"False is not true" suggests to the user that the test is doing an
identity check. We have proof from the OP's bug report that at least one
person thought that. I had to read the source code to check that it doesn't.

A better failure message would be helpful to make it clear that it
checks by value not identity ``if value is True``.
msg356126 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-06 12:58
If there is anything wrong with terms "true" and "false" (I don't know), we should fix this not only in one particular place, but everywhere. If there is nothing wrong with them, there is nothing to "improve". If this depends of the context, we should consider every occurrence case by case. Hope PR 17073 will help with this. It marks 665 of possible bugs so you can easily review these changes.
msg356179 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2019-11-07 09:22
Generally, „true“ and „false“ refer to „truthiness“, while the actual ``True`` and ``False`` literals should be capitalized. And in monospace font if possible.

I think this is a good convention, but it's quite subtle, and I don't think it's explicitly mentioned in the docs.
msg356206 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-11-07 18:13

> A correct failure message, correct both as English and Python, should be something like 'bool(x) is not True'.  I see 'x is not true' as an informal English equivalent of the full claim.

I'm not clear whether you're suggesting having something like "bool(x) is not True" be the actual failure message, but if you are, that makes a lot of sense to me. (My current advice to coworkers is always to include the "msg" attribute when using assertTrue and assertFalse, because the default message tends to be spectacularly unhelpful.)

-1 on introducing the terms "truthy" and "falsy" (or "falsey"?) into this one corner of Python. Given that those terms don't seem to be used elsewhere in the codebase, I'd expect introducing them here to cause more confusion, rather than less.
msg356208 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-07 18:48
In some cases "a true value" and "a false value" are used in the documentation. But in most cases it is just "true" and "false".
msg356211 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-11-07 19:45
See also issue38738.
Date User Action Args
2019-11-07 19:45:19serhiy.storchakasetmessages: + msg356211
2019-11-07 18:48:13serhiy.storchakasetmessages: + msg356208
2019-11-07 18:13:43mark.dickinsonsetnosy: + mark.dickinson
messages: + msg356206
2019-11-07 09:22:16petr.viktorinsetnosy: + petr.viktorin
messages: + msg356179
2019-11-06 12:58:09serhiy.storchakasetmessages: + msg356126
2019-11-06 12:47:21steven.dapranosetmessages: + msg356124
2019-11-06 11:48:14terry.reedysetnosy: - vinay.sajip, eric.smith

messages: + msg356120
versions: + Python 3.9, - Python 3.8
2019-11-06 10:54:10eric.smithsetnosy: + eric.smith
2019-11-06 10:41:00vinay.sajipsetnosy: + vinay.sajip
messages: + msg356114
2019-11-06 10:23:36serhiy.storchakasetstage: patch review
pull_requests: + pull_request16583
2019-11-06 08:15:41serhiy.storchakasetmessages: + msg356105
2019-11-06 08:11:22ammar2setmessages: + msg356104
2019-11-06 08:07:31serhiy.storchakasetnosy: + terry.reedy, rbcollins, ezio.melotti, r.david.murray, michael.foord
messages: + msg356103
2019-11-06 00:26:54ammar2setnosy: + ammar2
messages: + msg356083
2019-11-06 00:25:28steven.dapranosetstage: resolved -> (no value)
messages: + msg356082
versions: + Python 3.8, - Python 3.9
2019-11-06 00:23:26steven.dapranosetstatus: closed -> open

type: enhancement
versions: - Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8
nosy: + steven.daprano

messages: + msg356081
resolution: not a bug ->
2019-11-05 21:33:13serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg356067

resolution: not a bug
stage: patch review -> resolved
2019-11-05 21:20:47mkarotsierissetkeywords: + patch
stage: patch review
pull_requests: + pull_request16574
2019-11-05 21:20:16mkarotsierissetpull_requests: - pull_request16573
2019-11-05 21:16:19mkarotsieriscreate