Please reconsider the Boolean evaluation of midnight

Post by baq » Thu, Mar 06, 2014, 7:15 PM UTC

donaldstufft wrote: post #74

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…

You can't document your way out of a usability problem.

Post by mzs » Thu, Mar 06, 2014, 7:23 PM UTC

randlet wrote: post #15

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"

Post by _carljm » Thu, Mar 06, 2014, 7:31 PM UTC

bouk wrote: post #105

Python has weird ideas about comparisons, I'm pretty sure it's the only language where this is possible: https://eval.in/113749

Post by amirouche » Thu, Mar 06, 2014, 7:38 PM UTC

nbouscal wrote: post #39

tomp wrote: post #21

Earlier quoted context omitted.

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

Would you intentionally introduce language features that break functionality for people who don't follow style guidelines? I certainly hope not. The real problem with your argument is that the poorly-styled code of people who haven't learned better yet is in production . This isn't a theoretical exercise. This is a tool used in industry, and "teaching people to style their code better" is not a valid excuse for costi…

Post by icarus127 » Thu, Mar 06, 2014, 8:28 PM UTC

throwaway7808 wrote: post #112

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…

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' co…