Please reconsider the Boolean evaluation of midnight • Hacker News Board

Re: Please reconsider the Boolean evaluation of midnight

#71

Post by [deleted] » Thu, Mar 06, 2014, 4:51 PM UTC

mercurial wrote: post #65

yeukhon wrote: post #38

Earlier quoted context omitted.

If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empty. Unlike JS which has == and === , Python only offers == I like that. Coding like !=0 is very C like to me, or not taking advantage of Python. In the Python world, it is common and advised to test trutfulness until you have to test the actual value. That is,…

Starting to raise exceptions for non-exceptional conditions is bad code. And yes, I know that's how generators signal they are exhausted, but it's still bad code.

[deleted]

Re: Please reconsider the Boolean evaluation of midnight

#72

Post by hyperpape » Thu, Mar 06, 2014, 4:53 PM UTC

kingkilr wrote: post #58

hyperpape wrote: post #49

James Coglan recently pointed out that all of Python's falsy values are the additive identity of some type. Midnight fits the mold. This results in some weird results from an intuitive perspective, but is very principled and elegant in other ways. My one objection was that I don't know how None fits in.

Midnight is not the addittive identity of points in time. There is no additive identity because there is no addition operation. You're confusing the ``time`` type, with the ``timedelta`` type, which represents a duration, and does have 0-minutes as an additive identity. midnight is not, nor has it ever been, the "zero-time", it's simply a point whose typical representation contains some 0s. It is no more Falsey than…

You win: I was confusing those things! I was thinking times were treated as a timedelta ranging from 0 to 23 hours 59...

Re: Please reconsider the Boolean evaluation of midnight

#73

Post by tomchristie » Thu, Mar 06, 2014, 4:56 PM UTC

So ignoring the hype, here's the outcome-to-date...

The ticket was reconsidered, reopened and classified as a bug. http://bugs.python.org/msg212771

Nick Coghlan's dissection of the issue here: https://mail.python.org/pipermail/python-ideas/2014-March/02... is pretty much perfect - wonderful piece of technical writing!

Donald Stufft has expressed an interest in making the patch for this happen, and assuming all goes as planned this usage will raise a deprecation warning in 3.5 and be fully fixed in 3.6.

News in brief: User raises issue. Issue gets resolved.

Re: Please reconsider the Boolean evaluation of midnight

#74

Post by donaldstufft » Thu, Mar 06, 2014, 5:00 PM UTC

rkangel wrote: post #52

nbouscal wrote: post #13

If I understand the argument there correctly, the responder is saying: Nobody should ever use this functionality, instead they should always check that the date is not None. So, we should leave this broken, because we don't want to break backwards-compatibility with that class of applications that nobody should ever write. That philosophy, taken to its logical conclusion, results in everything being broken forever.

My understanding is that the responder is saying that "That test does not mean what you are intending it to mean, it means something else that we've documented. We won't make it mean what you would like it to take make your incorrect code work, at the expense of breaking code that is using it in the documented way". I started on the side of the original person but was persuaded round by the responder. "if x:" means s…

You can't document your way out of a usability problem.

Re: Please reconsider the Boolean evaluation of midnight

#75

Post by pyre » Thu, Mar 06, 2014, 5:05 PM UTC

mildtrepidation wrote: post #31

tehwalrus wrote: post #25

Earlier quoted context omitted.

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems. Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding wh…

So since we need to be explicit, it should be:

  if var in (None, 0, "", [], {}, ...):
    pass

something like that?

In general, most of those false-y values make sense. Midnight being a false-y value does not make sense. This seems to be a case of "we represent midnight as zero internally, and zero is false-y, so midnight should be false-y." This logic does not make sense to me. If they represented noon as 0 instead, should that evaluate to false, just because?

Re: Please reconsider the Boolean evaluation of midnight

#76

Post by pyre » Thu, Mar 06, 2014, 5:09 PM UTC

Cowen wrote: post #33

tehwalrus wrote: post #25

Earlier quoted context omitted.

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

I prefer the second one. Explicit is better than implicit.

If explicit is always better than implicit, why is Python dynamically typed?

Re: Please reconsider the Boolean evaluation of midnight

#77

Post by icambron » Thu, Mar 06, 2014, 5:09 PM UTC

rkangel wrote: post #52

nbouscal wrote: post #13

If I understand the argument there correctly, the responder is saying: Nobody should ever use this functionality, instead they should always check that the date is not None. So, we should leave this broken, because we don't want to break backwards-compatibility with that class of applications that nobody should ever write. That philosophy, taken to its logical conclusion, results in everything being broken forever.

My understanding is that the responder is saying that "That test does not mean what you are intending it to mean, it means something else that we've documented. We won't make it mean what you would like it to take make your incorrect code work, at the expense of breaking code that is using it in the documented way". I started on the side of the original person but was persuaded round by the responder. "if x:" means s…

> Changing the boolean evaluation in this case is actually making the mess even worse.

I don't see how that's possible. Assuming that using "if x:" is wrong (for some value of wrong) here, this issue only affects people who are using it wrong anyway. So all fixing it does is make the consequences of doing bad stuff less painful. I can't see how that would hurt things. Even if you think "if x:" should never be used on non-booleans, leaving land mines in there to hurt newbie (or lazy) developers is not a good way to enforce that convention. It just creates pain.

Or more simply: whether having boolean coercion for conditionals is a good idea is orthogonal to how such a coercion should work. It sounds like Python should deprecate truthiness altogether. But it hasn't, so in the meantime truthiness should work in a reasonable way, and falsy midnights are not reasonable.

Pointing out that it's documented is unhelpful (the documentation is just the wrongness restated in a different language), as is "That test does not mean what you are intending it to mean" (Tautological. The OP was suggesting changing what the test means).

Re: Please reconsider the Boolean evaluation of midnight

#78

Post by rdtsc » Thu, Mar 06, 2014, 5:09 PM UTC

nbouscal wrote: post #26

rdtsc wrote: post #23

Earlier quoted context omitted.

Python has truthiness and falsiness as well. That shortens code like: if not x: do_something() x could be 0, None, False, empty set set(), {}, [], (), '',"" or an I believe any class or object that appropriately overrides __nonzero__() or __bool__() methods. It is a matter of taste, so I rather like it.

It's not a matter of taste when it breaks functionality.

It depends on what x is and what do_something() does.

Most often than not in my code that wouldn't break functionality. In the case of dates it is broken, so same code pattern there would be broken.

At this point a lot more functionality would break if 0 become non-False or threw a TypeError exception.

Re: Please reconsider the Boolean evaluation of midnight

#79

Post by mildtrepidation » Thu, Mar 06, 2014, 5:11 PM UTC

pyre wrote: post #75

mildtrepidation wrote: post #31

Earlier quoted context omitted.

In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems. Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding wh…

So since we need to be explicit, it should be: if var in (None, 0, "", [], {}, ...): pass something like that? In general, most of those false-y values make sense. Midnight being a false-y value does not make sense. This seems to be a case of "we represent midnight as zero internally, and zero is false-y, so midnight should be false-y." This logic does not make sense to me. If they represented noon as 0 instead, shou…

If you need to use a test like that, you've already gone too far down the road of lazy "falsey" value usage, and whoever wrote it didn't bother with the idea of sensible defaults or consistent typing/initialization.

I agree that midnight evaluating to false is ridiculous (I wasn't aware of this, thankfully I've never run into it). I'm not sure where you got the idea that I support this, but I don't.

Re: Please reconsider the Boolean evaluation of midnight

#80

Post by mildtrepidation » Thu, Mar 06, 2014, 5:13 PM UTC

maxerickson wrote: post #63

mildtrepidation wrote: post #31

Earlier quoted context omitted.

In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems. Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding wh…

It's a rule of thumb, not a mantra. I suppose the hilarious way to argue it would be to say that there is an implicit "all other things being equal" in front of each of those.

Call it what you want; I'm not arguing it to be pedantic, I think it's a very practical approach. But if you prefer:

All other things being equal, I see no reason to write code that needlessly introduces potential bugs and maintainability issues by ignoring the rule of thumb that explicit trumps implicit.