Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please reconsider the Boolean evaluation of midnight

mail.python.org

Post reply on HN
Print view View original

111–120 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#111

Post by sanderjd »

josephlord wrote: post #69

I think the interesting part is what is revealed about Python and the difference with something like Ruby. Python is stable[0] and places a high degree of importance on backwards compatibility. This behaviour is well documented (and called out for particular note). This reinforces that it is (a) official and (b) not a bug because it is the documented behaviour. On the other hand Ruby (and most Ruby libraries) seem bo…

I'm gonna disagree with you! Well, I actually agree about ruby libraries, but the ruby standard library is the proper comparison here, which in my experience manages backwards compatibility and documentation of edge cases rather nicely. The (many) changes to the language itself since 1.8 have nearly all happened in backwards-compatible ways. So maybe the ruby community has a more flexible attitude (I've honestly never used enough external python libraries to have a good comparison point), but I don't think it's fair to say that the language itself is.

Re: Please reconsider the Boolean evaluation of midnight

#112

Post by throwaway7808 »

emillon wrote: post #35
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.

This is what is plaguing the ocaml compiler and standard library. Overconservatism with respect to obscure features. For example, a patch was written to speed up hashtables (IIRC), and was rejected because it would change the result of hashing format strings (type-safe format strings have a different type from plain strings). I can't imagine a single application where you would need to preserve the value of hashed fo…

Type-safe format strings should never be mixed with plain strings, constant strings, byte strings, unicode strings, batteries strings, byte array strings, char array strings, string buffers or any other type of string supported by ocaml. Keep your types pure and never mix them with any other types. Never. And you will never have any problem. And these python developers are lunatics. It is preposterous to use 'if' condition on a Date object and expect anything good. Idiots. They should have at least written a type-safe wrapper.

Re: Please reconsider the Boolean evaluation of midnight

#113

Post by clarkevans »

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...

Re: Please reconsider the Boolean evaluation of midnight

#114

Post by [deleted] »

famousactress wrote: post #30
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.

I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. I do hope the…

[deleted]

Re: Please reconsider the Boolean evaluation of midnight

#115

Post by barakm »

clarkevans wrote: post #113

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...

Came here to say this. It's the most useful statement in the entire thread of "you're wrong!" "no, you're wrong!" and nobody noticed.

Re: Please reconsider the Boolean evaluation of midnight

#116

Post by Zancarius »

cschmidt wrote: post #101
rkangel wrote: post #52

Earlier quoted context omitted.

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…

One of the most basic pages of python documentation [1] says this: Any object can be tested for truth value, for use in an if or while condition or as operand of the Boolean operations below. The following values are considered false: None False zero of any numeric type, for example, 0, 0L, 0.0, 0j. any empty sequence, for example, '', (), []. any empty mapping, for example, {}. instances of user-defined classes, if…

It's documented in the datetime module [1]:

    in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None), the result is non-zero.
But the only reason I know that is because I read a substantial part of the exchange where Mr. Paul Moore quotes it.

My initial reaction was to think "How the heck would you deduce midnight from this?" and I think arguing that the behavior is fully documented from this line alone is a bit of a stretch. It's true that it is documented, but not in a manner that is immediately obvious. Worse, there are 87 instances of "None" on that page, which makes searching for a specific issue somewhat daunting.

The irony (in terms of an unexpected side effect) is that by having the discussion they did, even if nothing comes of it in terms of fixes or changes, future developers bit by this behavior will be able to readily find it via a search for midnight, None values from time objects, etc.

[1] http://docs.python.org/3.4/library/datetime.html#time-object...

Edit: Left off the citation. Sorry. ;)

Re: Please reconsider the Boolean evaluation of midnight

#117

Post by mannykannot »

This offers a counterexample to the simplistic notion that 'duck typing' results in programs that automagically do the right thing. The reality is that duck typing does not relieve you of the responsibility of understanding the semantics of the elements you use to construct a program from.

Re: Please reconsider the Boolean evaluation of midnight

#118

Post by [deleted] »

barakm wrote: post #115
clarkevans wrote: post #113

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...

Came here to say this. It's the most useful statement in the entire thread of "you're wrong!" "no, you're wrong!" and nobody noticed.

[deleted]

Re: Please reconsider the Boolean evaluation of midnight

#119

Post by Zancarius »

cschmidt wrote: post #108
koenigdavidmj wrote: post #106

Earlier quoted context omitted.

For the purposes of that document, datetime is not a builtin type but a user-defined class (since it's written in a Python package and not the interpreter directly). It has a __nonzero__ method defined.

You're correct, it falls under that last rule of user-defined class. They certainly have a right to define it that way, in some sense. But it just goes entirely against the spirit of that documentation to do so. I would be fairly shocked if there are many other examples of exceptions to this rule in the standard library. That's just not how it is supposed to work. I'm primarily a python developer, and I have that lis…

I agree.

The issue I take with this behavior, or at least the justification for closing discussion of whether or not it's applicable (though I do agree it's not a "bug" per se, simply on the merit that it's documented--even if the documentation is unclear), is this notion that it would break code where this behavior is relied upon. First, you're assuming that someone understands the behavior clearly enough to exploit it (while there's obviously a non-zero population who aren't aware enough to avoid it). Second, you're assuming that they're not inclined to realize what an outrageously stupid idea it is to rely on midnight == False. If someone who's attempting to use truthiness as a means of determining if a time object (say, from a database) is None or falsey isn't aware of this behavior enough to not get bitten by it, what makes us think that the percentage of people who would be exploiting this behavior is somewhat higher? It's insanity. More so when each of the examples presented in the discussion for how it might be used are outrageous edge cases.

Now, would it be possible to workaround this by using datetimes, which as far as I can tell cannot be made falsey, then extract the time component later when needed after validating that the datetime is indeed not None? I can't think of any real world circumstances where you're not going to need to be aware of the date, timezone, and therefore DST when extracting times except for profiling or one-off quicky applications that don't need TZ awareness.

Post reply on HN