Please reconsider the Boolean evaluation of midnight

Post by cschmidt » Thu, Mar 06, 2014, 6:14 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…

    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 the class defines a __nonzero__() 
        or __len__() method, when that method returns the integer zero or bool value False. [1]

    All other values are considered true — so objects of many types are always true.

Post by lstamour » Thu, Mar 06, 2014, 6:17 PM UTC

pyre wrote: post #86

mildtrepidation wrote: post #79

Earlier quoted context omitted.

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.

It's functionality that someone went out of their way to create: def __bool__(self): if self.second or self.microsecond: return True offset = self.utcoffset() or timedelta(0) return timedelta(hours=self.hour, minutes=self.minute) != offset http://hg.python.org/cpython/file/302c8fdb17e3/Lib/datetime.... Now that I look at the actual code, it makes less sense. It's not just midnight that evaluates to False. It's midnig…

Post by bouk » Thu, Mar 06, 2014, 6:25 PM UTC

Post by rdtsc » Thu, Mar 06, 2014, 6:32 PM UTC

anon1385 wrote: post #36

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.

Well, if you read the mailing list thread there are several core python maintainers saying that is bad style. So I wouldn't call it just a matter of taste when core maintainers disagree with it and parts of the standard library break your code when you do it.

Post by sanderjd » Thu, Mar 06, 2014, 6:35 PM UTC

rkangel wrote: post #54

emillon wrote: post #35

Earlier quoted context omitted.

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…

It does sound like they might have gone a bit far, but as someone who works in an industrial context, a tool that maintains backwards compatibility rigorously is of enormous benefit. The case you might have to make to upgrade the version of the tool you are using has to take into account the risks, and something that is maintaining a high level of backwards compatibility has a much lower level of risk.