Live data from Hacker News

Please reconsider the Boolean evaluation of midnight

mail.python.org

141–150 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#141
post #21

Earlier quoted context omitted.

Equivalently, taken to its logical conclusion, it results in more people writing better code.

Would you intentionally introduce language features that break functionality for people who don't follow style guidelines? I certainly hope not. The real problem with your argument is that the poorly-styled code of people who haven't learned better yet is in production . This isn't a theoretical exercise. This is a tool used in industry, and "teaching people to style their code better" is not a valid excuse for costi…

>Would you intentionally introduce language features that break functionality for people who don't follow style guidelines?

Uhm maybe I'm confused but isn't that the whole design philosophy behind python? It makes bad indentation a syntax error!

Re: Please reconsider the Boolean evaluation of midnight

#142
Ignoring Python for a bit and thinking as a designer of some hypothetical future language: there is a nice rule given here for evaluation in a Boolean context. I wonder whether it should be taken as a general guideline for future languages.

The rule, in its entirety, is this:

- Booleans are falsy when false.

- Numbers are falsy when zero.

- Containers are falsy when empty.

- None is always falsy.

- No other type of value is ever falsy.

I can think of two ways we might possibly want to alter the rule.

The first is to expand the idea of number to include arbitrary groups (or monoids?), with the identity element being falsy. So, for example, a matrix with all entries zero might be falsy. Or a 3-D transformation might be falsy if it does not move anything.

The second is one I have encountered in C++. There, an I/O stream is falsy if it is in an error state. This makes error checking easy; there is one less member-function name to remember. We might expand this idea to include things like Python's urllib, or any object that wraps a connection or stream of some kind.

EDIT: OTOH, there is the Haskell philosophy, where the only thing that can be evaluated in a Boolean context is a Bool, so the only falsy thing is False.

EDIT 2: The comment by clarkevans (quoting a message from INADA Naoki) already partially addressed the above group idea: "I feel zero value of non abelian group should not mean False in bool context."

Re: Please reconsider the Boolean evaluation of midnight

#143

I think he understates the most powerful part of his argument. Midnight is a value, not a special value. There is no reason why it or any other valid time should be falsey on a daily cycle.

Couldn't the same argument be made about zero?

Zero has important, special properties not shared by any other number.

Re: Please reconsider the Boolean evaluation of midnight

#144

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

Abelian group is a sort of stringent requirement, they probably just mean a plain monoid? After all it works for python lists, which form a non-commutative monoid: [] + [] == [] [1,2] + [3] != [3] + [1,2]

The additional property which makes a monoid a group is the existence of inverse elements. So list is a good example for your point, because there are no "inverse lists".

Re: Please reconsider the Boolean evaluation of midnight

#145

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

And this is why programmers who know math are better programmers.

Re: Please reconsider the Boolean evaluation of midnight

#146

Why would anyone evaluate dates in a boolean context? They are (should be) always True.

> They are (should be) always True.

This is the obvious intuition, which doesn't match the current implementation.

> Why would anyone evaluate dates in a boolean context?

I'd guess, usually to tell whether a variable has a date or None. For example, maybe you have some kind of GUI with a form where the user is supposed to fill in a time, and some variable somewhere in the code is set to None [1] when the time field is blank [2], and a time object representing the time entered by the user otherwise.

Maybe you want to require the user to fill in all fields in the form before advancing to the next step in your program's workflow. If you like falsiness, you might write:

    if not form.time_field:
        show_warning("You must enter a time to proceed")
        continue_current_phase()
    else:
        proceed_to_next_phase()
You actually intended the first line to be:

    if form.time_field is not None:
But the only way you'd find this bug is when a user on the East Coast complains that the form won't accept 7:00 (UTC midnight). It will accept 6:59 or 7:01, but not 7:00. Of course you're on the West Coast, so you close their ticket as "can't reproduce" since 7:00 works just fine for you...

[1] None is the Python equivalent of other programming languages' null (or NULL).

[2] Or unparseable

Re: Please reconsider the Boolean evaluation of midnight

#147

Ignoring Python for a bit and thinking as a designer of some hypothetical future language: there is a nice rule given here for evaluation in a Boolean context. I wonder whether it should be taken as a general guideline for future languages. The rule, in its entirety, is this: - Booleans are falsy when false. - Numbers are falsy when zero. - Containers are falsy when empty. - None is always falsy. - No other type of v…

Making anything besides booleans "truthy" strikes me as asking for a lot of trouble for very little gain. For each of these cases, how hard is this to write:

    x == 0
    isempty(x)
    x == nothing
How much clearer is the intent of that code than a truthy boolean test would be? This clarity is all the more important in dynamically typed languages without type annotations since the code itself doesn't give any hint what the type of `x` might be, so the programmer doesn't know what it is the test is really checking for.

Oh the other hand, the cost of truthiness is pretty significant. Each person reading or writing code in a language with truthiness must remember all the arbitrary truthiness rules that particular language uses – and they're quite different for each of Python, Perl, Ruby, C, JavaScript, etc. As this issue demonstrates, whenever you open the door a little, even in a generally sane language like Python, at some point some weird decisions get made and you find yourself with some strange corner cases like midnight being falsey. If you wanted to know if a date was midnight, wouldn't it be easy enough to just explicitly test that?

Re: Please reconsider the Boolean evaluation of midnight

#148

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

This is a nice clean criterion, but it's still pretty unclear to me why the zero element of a monoid should be considered falsey at all.

Re: Please reconsider the Boolean evaluation of midnight

#149

Ignoring Python for a bit and thinking as a designer of some hypothetical future language: there is a nice rule given here for evaluation in a Boolean context. I wonder whether it should be taken as a general guideline for future languages. The rule, in its entirety, is this: - Booleans are falsy when false. - Numbers are falsy when zero. - Containers are falsy when empty. - None is always falsy. - No other type of v…

[deleted]

Re: Please reconsider the Boolean evaluation of midnight

#150

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

If that were true, it would mean that dict should not support bool:

    >>> {} + {}
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unsupported operand type(s) for +: 'dict' and 'dict'
    >>> bool({})
    False
Since I find bool(a_dict) to be very useful, and the lack of a_dict+b_dict to be reasonable (precisely because it's non-abelian!), I conclude that logic is cute, but not that relevant.

Those who think it this argument is pursuasive, should bool({}) raise an exception? Or should {1:"A"}+{1:"B"} not raise an exception and instead return ... what?

Or do I misunderstand something?

Post reply on HN