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

51–60 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#51

Post by tehwalrus »

jofer wrote: post #42
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: ...

Not in python. if var: ... is better in some situations, but is objectively worse in many others. If you really do want anything that's "falsey" to fall into that conditional, then by all means, use it! Just be aware that `0`, `[]`, `None`, `0.0`, etc will all be treated the same. However, it's harmful in one of its most common use cases: default values. For example, let's say you're working with a function that take…

default values is a special case (and one which I consider to be a bug in python, frankly, since it bites everyone who didn't read up on default arguments before the wrote some code - everyone uses [] as a default argument at some point and then spends an amount of time proportional to the complexity of their program debugging the insane behaviour before noticing. My program was quite long and complex, and I am still bitter.)

I didn't argue, and certainly didn't mean to imply, that it is always better, but in the sort of case we're considering in this example, i.e. we expect a valid time value or None, It really is madness to imply a time value of midnight is "empty".

Re: Please reconsider the Boolean evaluation of midnight

#52

Post by rkangel »

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 something completely different than "if x is not None", adn that needs to be understood. The fact that they might evaluate to the same result a lot of the time is luck, and is how people have got into this mess. Changing the boolean evaluation in this case is actually making the mess even worse.

Re: Please reconsider the Boolean evaluation of midnight

#53

Post by josephlord »

tomp wrote: post #21
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.

Equivalently, taken to its logical conclusion, it results in more people writing better code.

No, it doesn't just different mistakes.

If they wanted to make people write better code they would throw an error on coercion from time to bool so that everyone would have to fix the code.

Re: Please reconsider the Boolean evaluation of midnight

#54

Post by rkangel »

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…

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.

Re: Please reconsider the Boolean evaluation of midnight

#55

Post by Iftheshoefits »

tehwalrus wrote: post #47
batmansbelt wrote: post #29

Earlier quoted context omitted.

By what criteria have you decided that?

quicker to scan-read ("code will be read many more times than it is written or modified", being the relevant axiom)

Reading code is a purposeful activity, though; namely, to understand what the code does. The speed with which that can be done is relevant in the margins from a productivity standpoint, but to build an argument for code structure around it strikes me as missing the point of the "axiom" you quote.

Re: Please reconsider the Boolean evaluation of midnight

#56

Post by nbouscal »

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…

I understand the distinction between the two ways of writing the conditional. The point is that the documented way is surprising, and as far as I can tell everyone agrees that it is wrong. It's really not a matter of making the original poster's code work, it's a matter of making the language constructs have the expected behavior. Everyone seems to agree that code that used this behavior in the documented way would be bad code. That being the case, I see no way in which changing the behavior to the expected behavior would make anything worse.

Re: Please reconsider the Boolean evaluation of midnight

#57

Post by colanderman »

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.

How is "midnight" an additive identity? It's not a time delta. "+0 hours" is an additive identity. (And if Python's time library doesn't distinguish between absolute and relative times, that's a design flaw.)

That's like saying "north" is an additive identity on a compass. It's not; "+0° clockwise" is an additive identity.

Re: Please reconsider the Boolean evaluation of midnight

#58

Post by kingkilr »

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 the origin (0, 0) in the cartesian coordinate system is Falsey.

Re: Please reconsider the Boolean evaluation of midnight

#59

Post by kingkilr »

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…

Python already comes with the logical conclusion of goto-fail out of the box. There's no need to add a new special feature for it.

(There is absolutely no certificate store checking for certs by default, nor is there any hostname checking, or any of the myriad of other checks one might expect a reasonable TLS implementation to perform. Use the requests module.)

Re: Please reconsider the Boolean evaluation of midnight

#60

Post by donaldstufft »

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.

To take it from the same James Coglan -> "You can't add midnight to 3-o'clock in the same way you can't add London to Chicago."
Post reply on HN