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

31–40 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#31

Post by mildtrepidation »

tehwalrus wrote: post #25
tomp wrote: post #21

Earlier quoted context omitted.

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

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems.

Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding what's going on means looking at all invocations of that function to see what's being passed in.

Further, in that scenario, it's possible that different types are being passed for that argument. While "if var" could make this work where "if var is not None" would break functionality, in my opinion, it should break. Without getting into arguments about static typing, "truthiness" allows both sloppy code and the accidental introduction of bugs that might otherwise be caught during development due to faulty logic from vague conditional checks.

Re: Please reconsider the Boolean evaluation of midnight

#33

Post by Cowen »

tehwalrus wrote: post #25
tomp wrote: post #21

Earlier quoted context omitted.

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

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

I prefer the second one.

Explicit is better than implicit.

Re: Please reconsider the Boolean evaluation of midnight

#34

Post by delinka »

Not being a Pythonista, I have the following questions:

1) Is there a (native or custom) date type in Python? Is it an object?

2) Midnight when? Today? This date last year? Sure there's a "zero value" for dates - it's the epoch for whichever platform or library you're using.

3) Why in would anyone call it a "date" if it's really a time?

Maybe I'm getting off into the philosophical decisions of the reptile wranglers, but this particular debate sounds a lot like someone made a decision long ago that had ramifications further than expected and now the justification is engrained, things are built on it, and no one's willing to make the 'correction.'

Re: Please reconsider the Boolean evaluation of midnight

#35

Post by emillon »

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 format strings. But specifying their value so that you can rely on them just seems to be a bad idea.

Re: Please reconsider the Boolean evaluation of midnight

#36

Post by anon1385 »

rdtsc wrote: post #23
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.)

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.

Re: Please reconsider the Boolean evaluation of midnight

#37

Post by mildtrepidation »

delinka wrote: post #34

Not being a Pythonista, I have the following questions: 1) Is there a (native or custom) date type in Python? Is it an object? 2) Midnight when ? Today? This date last year? Sure there's a "zero value" for dates - it's the epoch for whichever platform or library you're using. 3) Why in would anyone call it a "date" if it's really a time ? Maybe I'm getting off into the philosophical decisions of the reptile wranglers…

Python has dates, times, and datetimes[0]. They're all objects. So yes, you could get around this by always using a datetime. However, sometimes what you need is just a time.

[0] http://docs.python.org/2/library/datetime.html

Re: Please reconsider the Boolean evaluation of midnight

#38

Post by yeukhon »

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

If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empty. Unlike JS which has == and ===, Python only offers == I like that. Coding like !=0 is very C like to me, or not taking advantage of Python. In the Python world, it is common and advised to test trutfulness until you have to test the actual value. That is, you can get away with a lot of if object instead of if object.size == 0 or if function() == 0, i think you can do this by implementing your own __eq__ and __nq__ for the object. Imagine someone has multiple values to return depending on the logic branch, the following is arguably ugly and bad, but say it happens:

   if cond1:
     return -1
   elif cond2:
     return -2
   elif cond3:
     return -3
Unless there is a good reason to return these ints, if you only care about the semantic (to distinguish which branch in the caller's), just raise your own exception.

   if cond1:
     raise cond1Exception
   elif
     raise cond2Exception
So there are ways to go around and make code more readable. is this a bad coding? Each has its own taste.

Re: Please reconsider the Boolean evaluation of midnight

#39

Post by nbouscal »

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.

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 costing industrial users of the language money.

Further, Python markets itself as a beginner-friendly language. Your attitude is the exact opposite of beginner-friendly.

Re: Please reconsider the Boolean evaluation of midnight

#40

Post by windsurfer »

Cowen wrote: post #33
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: ...

I prefer the second one. Explicit is better than implicit.

The second what?
Post reply on HN