Earlier quoted context omitted.
I prefer the second one. Explicit is better than implicit.
The second what?
The second example:
if var is not None:
...Please reconsider the Boolean evaluation of midnight
81–90 of 218 posts
Re: Please reconsider the Boolean evaluation of midnight
#82Lots 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.
But, it's represented internally as zero. That's reason enough!
Re: Please reconsider the Boolean evaluation of midnight
#83Earlier quoted context omitted.
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 wh…
If you shouldn't use non-booleans in an if statement, then why is it allowed? If it's allowed, it should behave in the way that would surprise developers the least.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Re: Please reconsider the Boolean evaluation of midnight
#84If 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.
Re: Please reconsider the Boolean evaluation of midnight
#85Earlier quoted context omitted.
I prefer the second one. Explicit is better than implicit.
If explicit is always better than implicit, why is Python dynamically typed?
Because at the time it was originally written, it seemed impossible to write a statically typed language that was beautiful, or even readable.
This has now proven to be false, and python is starting to add optional type annotations. It's not practical to introduce static typing more quickly - it would break too many existing programs.
Re: Please reconsider the Boolean evaluation of midnight
#86Earlier quoted context omitted.
So since we need to be explicit, it should be: if var in (None, 0, "", [], {}, ...): pass something like that? In general, most of those false-y values make sense. Midnight being a false-y value does not make sense. This seems to be a case of "we represent midnight as zero internally, and zero is false-y, so midnight should be false-y." This logic does not make sense to me. If they represented noon as 0 instead, shou…
If you need to use a test like that, you've already gone too far down the road of lazy "falsey" value usage, and whoever wrote it didn't bother with the idea of sensible defaults or consistent typing/initialization. I agree that midnight evaluating to false is ridiculous (I wasn't aware of this, thankfully I've never run into it). I'm not sure where you got the idea that I support this, but I don't.
It's functionality that someone went out of their way to create:
def __bool__(self):
if self.second or self.microsecond:
return True
offset = self.utcoffset() or timedelta(0)
return timedelta(hours=self.hour, minutes=self.minute) != offset
Now that I look at the actual code, it makes less sense. It's not just midnight that evaluates to False. It's midnight UTC that evals to False. So if your timezone is PST, then 8AM evals to False. Since most datetime.time() objects are timezone 'dumb' by default, this distinction doesn't matter so much, but I can see this still biting some people hard, even if "Midnight is false-y" made sense.
Edit: Also, to the "explicit is better than implicit" crowd, notice this line (in core libs):
if self.second or self.microsecond:
return True
if self.second != 0 or self.microsecond != 0:
return True
Edit: s/EST/PST/ ^^;;
Re: Please reconsider the Boolean evaluation of midnight
#87James 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."
As far as I understand from reading that whole thread, this is, ironically, precisely why local midnight evaluates to False. They left in an escape hatch to support the illogical idea of addition.
Re: Please reconsider the Boolean evaluation of midnight
#88The only reason for midnight being a falsy value that I can think of is that someone thought that all objects should provide some functionality for __nonzero__/__bool__.
It was a bad idea.
Re: Please reconsider the Boolean evaluation of midnight
#89Earlier quoted context omitted.
It's a rule of thumb, not a mantra. I suppose the hilarious way to argue it would be to say that there is an implicit "all other things being equal" in front of each of those.
Call it what you want; I'm not arguing it to be pedantic, I think it's a very practical approach. But if you prefer: All other things being equal, I see no reason to write code that needlessly introduces potential bugs and maintainability issues by ignoring the rule of thumb that explicit trumps implicit.
It's an old argument. I don't have real strong feelings about it. I think there is enough code doing one or the other out there that the end result is to understand well the ramifications of both, so it ends up a matter of taste.
The documentation is pretty clear about it:
http://docs.python.org/release/3.3.4/library/stdtypes.html#t...
Which leads to this:
>>> a=object()
>>> bool(a)
True
>>>Re: Please reconsider the Boolean evaluation of midnight
#90Earlier 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.
There's a lot of maintainers who seem convinced otherwise.