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/case.py .

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.

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.

Since error messages aren't part of the API and backwards-compatibility doesn't apply to them, this could still go into 3.8.

I like Steven's "truthy value" or "true value" proposal. Another alternative:

"x does not evaluate to true"
"x does not evaluate to false"

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.

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`?

There are almost 500 occurrences of "is true".

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!

I pretty strongly dislike 'truthy' and 'falsey'.  They look slangy and https://en.wiktionary.org/wiki/truthy 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.

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

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.

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.

[Terry]

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

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

See also issue38738.

I tried sending this message earlier, but it seems to have disappeared 
into the void, so I'm trying again. Apologies if it turns up twice.

* * *

> 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 assertIsTrue and 
assertIsFalse 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.

A better failure message would be helpful to make it clear that it 
checks by value not identity ``if value is True``.