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

161–170 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#161

Post by davidcuddeback »

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

I just tried this:

    $ python
    >>> import time, datetime
    >>> () + ()
    ()
    >>> "" + ""
    ''
    >>> 0 + 0
    0
    >>> datetime.timedelta() + datetime.timedelta()
    datetime.timedelta(0)
    >>> time.time() + time.time()
    27848327051.323207
Seems like time() + time() is not a TypeError in Python.

Re: Please reconsider the Boolean evaluation of midnight

#162

Post by axman6 »

pyre wrote: post #82
ameoba wrote: post #20

Earlier quoted context omitted.

Falsey objects mean "there's no data here" which is why they're falsey. Having an empty list of arguments to a command is the same as having no argument list. There's nothing about midnight that makes sense for it to behave as Falase.

But, it's represented internally as zero. That's reason enough!

That's an implementation detail and should be open to change without breaking things.

Re: Please reconsider the Boolean evaluation of midnight

#163

Post by nknighthb »

iandanforth wrote: post #84
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.

Yes. This is where Linus would step in and say "SHUT THE FUCK UP! We don't break user space, EVER!" Developers who enter into the mindset that the users of their code are using it "wrong" are a blight and will always be a blight. Too bad Python has a BDFL and not a Raging DFL.

Some things are really hard on users when they break. Kernels are especially hard, because only one can run on a (non-virtualized) system at a time. System libcs are pretty hard, ditto init systems and some other deep infrastructure.

Language interpreters can be annoying, but not to the same degree. It is quite easy to run multiple Python versions on one system. It's also relatively easy to find and fix the broken Python code in a case like this -- it's always sitting there on your drive, open for inspection. And it's not black magic -- anyone with a little programming experience, even if it's not in Python, can easily understand the issue and the fix, and make the appropriate change.

Nuance matters, and unlike a boolean, principles are not always binary choices.

Re: Please reconsider the Boolean evaluation of midnight

#164

Post by Aramgutang »

davidcuddeback wrote: post #161
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...

I just tried this: $ python >>> import time, datetime >>> () + () () >>> "" + "" '' >>> 0 + 0 0 >>> datetime.timedelta() + datetime.timedelta() datetime.timedelta(0) >>> time.time() + time.time() 27848327051.323207 Seems like time() + time() is not a TypeError in Python.

Wrong time(), you want datetime.time().

time.time() returns the seconds elapsed since the epoch.

Re: Please reconsider the Boolean evaluation of midnight

#165

Post by aiiane »

dalke wrote: post #157
mctx wrote: post #154

Earlier quoted context omitted.

{1: ["A", "B"]}?

Okay, then what about {1: "A"} + {} Should that return {1: ["A"]}? In which case {} is no longer a zero value. What about {1: "A"} + {} + {1: "B", 2: "Z"} + {1: "C"} + {} In any case, your suggestion would break all existing code. Based on all the StackOverflow and python-list questions, most people expect one or the other value, and few want the two-element list containing both. (And why a list instead of a tuple?)…

How does {1:"A"}+{} = {1:"A"} imply that {} is no longer a zero value? 1+0=1 makes total sense...

Re: Please reconsider the Boolean evaluation of midnight

#166

Post by Pacabel »

army wrote: post #97
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.

I would agree with his approach, but unfortunately the Python community has encouraged, to some extent at least, the use of implicit "truthiness" to do things like check for None, rather than explicit checks.

I'm not sure if I'd say that it's the Python community that has encouraged that practice.

I think it's more likely just a bad habit that some people may have picked up when using PHP or JavaScript, and mistakenly continued using after moving to Python.

PEP 8 (http://legacy.python.org/dev/peps/pep-0008/#programming-reco...) is quite clear about this:

"Comparisons to singletons like None should always be done with is or is not, never the equality operators.

Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!"

PEP 8 is more representative of the actual Python community's views than the mistakes of some programmers who are more accustomed to certain languages that are not Python.

Re: Please reconsider the Boolean evaluation of midnight

#167

Post by Pacabel »

nas wrote: post #18
RyanMcGreal wrote: post #12

Earlier quoted context omitted.

Explicit is better than implicit. Simple is better than complex.

I'm not sure what that is supposed to mean in this context. Testing for "is not None" is more explicit and avoids the trap being discussed. I don't know how the second sentence applies, maybe "if timeval:" is simpler? BTW, do you know the original author of the Zen of Python has posted to this very dicussion (while also being the orginal author of said module): https://mail.python.org/pipermail/python-ideas/2014-Marc…

"Simplicity" is not measured in terms of key presses or characters.

The "if timeval:" case may contain fewer characters, but it's less explicit. Being less explicit opens it up to greater ambiguity. Ambiguity is a form of complexity. Complexity is the opposite of simplicity.

The explicit "is not None" check may require more typing, but it's far more explicit and exact. That means it's much less ambiguous, and thus less complex, and thus exhibits greater simplicity.

Re: Please reconsider the Boolean evaluation of midnight

#168

Post by dalke »

aiiane wrote: post #165
dalke wrote: post #157

Earlier quoted context omitted.

Okay, then what about {1: "A"} + {} Should that return {1: ["A"]}? In which case {} is no longer a zero value. What about {1: "A"} + {} + {1: "B", 2: "Z"} + {1: "C"} + {} In any case, your suggestion would break all existing code. Based on all the StackOverflow and python-list questions, most people expect one or the other value, and few want the two-element list containing both. (And why a list instead of a tuple?)…

How does {1:"A"}+{} = {1:"A"} imply that {} is no longer a zero value? 1+0=1 makes total sense...

It's not just that one expression, but when done in addition to the previous suggested answer. That is, what is the type of the values in the summed dictionaries?

If {1:"A"}+{} == {1:"A"} then the type of each value is unchanged from the input list.

If {1:"A"}+{1:"B"} == {1:["A","B"]} then the type of each value (or at least each shared value) is a 2-element list.

If both are true, then no one can write sane code which knows how deal with the sum of two dictionaries.

That is, the insane code has to have checks for if one of the dictionaries is empty, and if so, do one thing, otherwise do another thing. In which case, why is this definition useful?

Therefore, either {} is the zero value, or dictionary summation produces lists for the resulting values, but not both.

Re: Please reconsider the Boolean evaluation of midnight

#169

Post by anamexis »

aiiane wrote: post #165
dalke wrote: post #157

Earlier quoted context omitted.

Okay, then what about {1: "A"} + {} Should that return {1: ["A"]}? In which case {} is no longer a zero value. What about {1: "A"} + {} + {1: "B", 2: "Z"} + {1: "C"} + {} In any case, your suggestion would break all existing code. Based on all the StackOverflow and python-list questions, most people expect one or the other value, and few want the two-element list containing both. (And why a list instead of a tuple?)…

How does {1:"A"}+{} = {1:"A"} imply that {} is no longer a zero value? 1+0=1 makes total sense...

In the comment above, the hypothetical result is {1:["A"]}, not {1:"A"}. (The value is in a list.)

Re: Please reconsider the Boolean evaluation of midnight

#170

Post by pyre »

axman6 wrote: post #162
pyre wrote: post #82

Earlier quoted context omitted.

But, it's represented internally as zero. That's reason enough!

That's an implementation detail and should be open to change without breaking things.

My post was meant to be sarcastic. I thought it was ridiculous enough to not need something indicating sarcasm though...
Post reply on HN