This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients mark.dickinson, rhettinger, serhiy.storchaka, terry.reedy
Date 2017-03-24.20:49:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1490388593.49.0.730597412657.issue29840@psf.upfronthosting.co.za>
In-reply-to
Content
https://docs.python.org/3/library/functions.html#bool refers to
https://docs.python.org/3/library/stdtypes.html#truth

The latter says that values are true ("All other values are considered true") unless one of certain conditions holds.  For user-defined classes, the condition is that the class defines a __bool__() or __len__() method and that the first of those methods returns the bool False or integer zero.

I easily interpret this as meaning that bool(x) (should) *always* return True or False.  In particular, for user classes, any exception in user-coded __bool__ or __len__ (should be) included in "does not return integer zero or bool value False".  This would mean that 'True' would truly be the default return for Bool().

There is currently an unstated exception for raised Exceptions.  This issue proposes an exception to the exception for OverflowErrors (once negative lengths consistently raise ValueErrors and never OverflowErrors).  While this sensible in itself, I am completely happy with the added complication.  I would like to either reconsider the exception for Exceptions or make it explicit.

Patch has new text and What's New entry.  Added logic in object.c looks correct.
History
Date User Action Args
2017-03-24 20:49:53terry.reedysetrecipients: + terry.reedy, rhettinger, mark.dickinson, serhiy.storchaka
2017-03-24 20:49:53terry.reedysetmessageid: <1490388593.49.0.730597412657.issue29840@psf.upfronthosting.co.za>
2017-03-24 20:49:53terry.reedylinkissue29840 messages
2017-03-24 20:49:53terry.reedycreate