Documentation says:
> Match objects always have a boolean value of True. Since match() and
> search() return None when there is no match, you can test whether 
> there was a match with a simple if statement:
>
> match = re.search(pattern, string)
> if match:
>     process(match)

What happens:
blah = <_sre.SRE_Match object; span=(0, 28), match='<BR>Nov. 10, 08:16:09 PM EST'>
     if blah == True:
           print("True")
     if blah:
            print('blah True')

blah True
///

Blah is not True

One suggestion: instead, the passage above should say “evaluates true in a boolean context”.

That's what "have a boolean value of True" means.  (ie: bool(<matchobject>) is True).  I'm neutral on whether or not it is worth changing the wording.

"evaluates true" should not be used in any case, the objects do not equal to True in any case.

The phrase "is considered true in a boolean context" is already in the docs and could be used here too.

The current wording of the passage “Match objects always have a boolean value of True” implies that the value compares equal to the ‘True’ constant. That implication is incorrect.

I disagree with R. David Murray; if we want to say that a value is considered true *in a boolean context*, that's very different from saying it has the “True” value.

Georg, “evaluates true in a boolean context” has the meaning you're seeking; it is chosen precisely because it does *not* imply equality to the True constant.

David is correct that the current phrasing is correct.  The phase 'x has a boolean value of True' means 'bool(x) is True', which is always true for match objects, as well as for non-zero numbers, non-empty collections, and many other things.  This does *not* imply equality between the object and its boolean value.  In fact, nearly all objects are not equal to their boolean value.  Clayton could just as well as have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-surprising result.

There is nothing special about boolean values in this respect.  The string value of x is str(x) and in general, x != str(x).  (This also sometimes confuses people.)  Similarly, if x has an integral value int(x), it does not necessarily equal that value: int(3.1459) != 3.

I think the doc is fine as is.  The fact that "3 is considered to be '3' in a display context" does not mean that we do not write "the string value of 3 is '3'".  It is fundamental to Python that essentially all objects o have a string value str(o) and a boolean value bool(o) and that those mappings are sometimes used automatically for display and logic.

Cool

>-----Original Message-----
>From: Terry J. Reedy [mailto:report@bugs.python.org]
>Sent: Friday, November 14, 2014 1:04 PM
>To: crk@godblessthe.us
>Subject: [issue22843] doc error: 6.2.4. Match Objects
>
>
>Terry J. Reedy added the comment:
>
>David is correct that the current phrasing is correct.  The phase 'x has
>a boolean value of True' means 'bool(x) is True', which is always true
>for match objects, as well as for non-zero numbers, non-empty
>collections, and many other things.  This does *not* imply equality
>between the object and its boolean value.  In fact, nearly all objects
>are not equal to their boolean value.  Clayton could just as well as
>have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-
>surprising result.
>
>There is nothing special about boolean values in this respect.  The
>string value of x is str(x) and in general, x != str(x).  (This also
>sometimes confuses people.)  Similarly, if x has an integral value
>int(x), it does not necessarily equal that value: int(3.1459) != 3.
>
>I think the doc is fine as is.  The fact that "3 is considered to be '3'
>in a display context" does not mean that we do not write "the string
>value of 3 is '3'".  It is fundamental to Python that essentially all
>objects o have a string value str(o) and a boolean value bool(o) and
>that those mappings are sometimes used automatically for display and
>logic.
>
>----------
>nosy: +terry.reedy
>
>_______________________________________
>Python tracker <report@bugs.python.org>
><http://bugs.python.org/issue22843>
>_______________________________________