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

11–20 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#11

Post by Nanzikambe »

Whilst reading that thread, I stumbled accross:

  "goto fail" is a well-known error handling mechanism in open source 
  software, widely reputed for its robusteness:
  
  http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c
  
  https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c
  
  I believe Python needs to add support for this superior paradigm.
  
  It would involve a new keyword "fail" and some means of goto'ing to it. 
  I suggest "raise to fail":
  
  if (some_error):
     raise to fail
  
  fail:
        
  
  Unless there are many objections, this fantastic idea might be submitted 
  in a (short) PEP somewhere around the beginning of next month.
  
  There is some obvious overlap with the rejected "goto PEP" (PEP 3163) 
  and the Python 2.3 goto module. However, the superiority of goto fail as 
  error generation and error handling paradigm has since then been 
  thoroughly proven.
https://mail.python.org/pipermail/python-ideas/2014-March/02...

Re: Please reconsider the Boolean evaluation of midnight

#12

Post by RyanMcGreal »

nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "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" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

Explicit is better than implicit.

Simple is better than complex.

Re: Please reconsider the Boolean evaluation of midnight

#13

Post by nbouscal »

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.

Re: Please reconsider the Boolean evaluation of midnight

#14

Post by mercurial »

nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "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" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

That's why the user was suggesting deprecating the feature.

Re: Please reconsider the Boolean evaluation of midnight

#15

Post by randlet »

wzdd wrote: post #10

Lots of Python objects are falsey: empty lists, empty strings, etc. So it's never a good idea to write "if " when you mean "if is not None". This is pretty well-known, I thought.

A big part of it is about user expectations. I would be shocked if any experienced Python programmer who wasn't familiar with this exact implementation detail expected the following:

    if datetime.time(0, 0, 0):
        print "foo"
    else:
        print "bar"
to print "bar"

Re: Please reconsider the Boolean evaluation of midnight

#16

Post by mercurial »

Nanzikambe wrote: post #11

Whilst reading that thread, I stumbled accross: "goto fail" is a well-known error handling mechanism in open source software, widely reputed for its robusteness: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c I believe Python needs to add support for this superior…

Picking on C's error handling mechanism is like picking on its non-existent standard library: it's been done to death.

Re: Please reconsider the Boolean evaluation of midnight

#17

Post by colanderman »

I've never seen a good argument for anything beside "false" to be considered false. Likewise for "true". Keystrokes are not a commodity for most coders, and compilers are not dumb; just be explicit and write "!= 0" or whatever.

(And 0 == False, "" != False, but both 0 and "" are considered false? C'mon Python, that's borderline JavaScript territory.)

Re: Please reconsider the Boolean evaluation of midnight

#18

Post by nas »

RyanMcGreal wrote: post #12
nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "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" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

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-March/02... https://mail.python.org/pipermail/python-ideas/2014-March/02...

Re: Please reconsider the Boolean evaluation of midnight

#19

Post by nbouscal »

colanderman wrote: post #17

I've never seen a good argument for anything beside "false" to be considered false. Likewise for "true". Keystrokes are not a commodity for most coders, and compilers are not dumb; just be explicit and write "!= 0" or whatever. (And 0 == False, "" != False, but both 0 and "" are considered false? C'mon Python, that's borderline JavaScript territory.)

I really don't think there is a good argument. Any time saved in writing the code is inevitably repaid in debugging it.

Re: Please reconsider the Boolean evaluation of midnight

#20

Post by ameoba »

wzdd wrote: post #10

Lots of Python objects are falsey: empty lists, empty strings, etc. So it's never a good idea to write "if " when you mean "if is not None". This is pretty well-known, I thought.

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.

Post reply on HN