Let's turn this around. Aside from backwards compatibility, what benefit is there from having midnight evaluate as false?

On Wednesday, March 5, 2014 9:09:50 AM, Skip Montanaro <skip@pobox.com> wrote:
On Wed, Mar 5, 2014 at 9:15 AM, Shai Berger <shai@platonix.com> wrote:
> Also, when opening this thread, I argued that 0 is special,
> but midnight is not -- which you completely ignore.

Zero is not different, at least when considered as an element of a set
(of integers, in my example). What's important is that we have a set
of values (either time objects or integers in these two examples) and
need some way to specify a sentinel value. That sentinel must not be
in the set of valid values. In both of these cases, None fills the
bill. Note that the only reasonable relationship between None and
either the set of all time objects or the set of all integers is that
it is not a member of either set. Testing that membership by appealing
to their value cast to a boolean is simply wrong.

I'll push the argument just a bit further. Suppose you have an
attribute which corresponds to the setting of a two-valued sensor
external to your system. You choose to represent those two values in
your program as True and False. You need a way to tell if any sensor
inputs have been detected yet, or not, so you initialize the attribute
with a sentinel value. I don't care what value you choose out of all
the possible sentinel values available to you (None, [], ["xyz"], {},
7, 0.0, etc), treating any of them as a boolean will be wrong. If you
do, you will erroneously always believe that your sensor has produced
a value.

I have made this sort of mistake many times over the years, and seen
other people do it as well. If what you really want to test is
membership of a value in a set, be explicit about it.

Skip
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/