I think he understates the most powerful part of his argument. Midnight is a value, not a special value. There is no reason why it or any other valid time should be falsey on a daily cycle.
Couldn't the same argument be made about zero?
Please reconsider the Boolean evaluation of midnight
131–140 of 218 posts
Re: Please reconsider the Boolean evaluation of midnight
#132Earlier quoted context omitted.
I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. I do hope the…
"0 is False" is extremely useful to a Pythonista. Ever indexed into an array with a boolean offset? Yes, you can do that. (False is 0, True is 1). Makes for very succinct code.
>>> bool() == int()
TrueRe: Please reconsider the Boolean evaluation of midnight
#133If 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…
Python, to its credit, has been making changes of that level.
First, True and False were just the integers 1 and 0. Then they were given special values that numerically evaluated to 1 and 0, but __str__ now emitted 'True' or 'False'. They were still global variables, though, so they could be reassigned ('True, False = False, True') and cost a dictionary lookup to use. Finally, with Python 3, they (along with None) were made keywords so that such shenanigans could be stopped.
Re: Please reconsider the Boolean evaluation of midnight
#134Earlier quoted context omitted.
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…
beginner-friendly doesn't mean stupid-friendly. And I am in favor of "teaching people to style their code better" in the language even if in this case, it's not about style but the meaning of midnight. semantic != style. Also, language must also help/structure/offer rails for thinking, create et cetera. Industry must bend before truth, not bend truth over itself...
We have mostly the same principles but have come to different conclusions. The semantics of midnight are indeed what is important here, but midnight does not qualify as a zero. Zero implies identity for some addition, and there is no addition for which midnight is the identity. This is because midnight does not even support addition: you have to use timedeltas if you want to add times. Timedelta 0, then, is the proper zero, and should semantically be falsy in languages where zeros are falsy. Midnight, on the other hand, should not be. (The entire notion of falsiness is terrible and should crawl off somewhere and die, but that's beside the point.)
Re: Please reconsider the Boolean evaluation of midnight
#135If 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…
Similar issues plague Haskell. A bunch of functions have illogical names, just because that's how they've always been used. And, there's the annoying matter of Applicative not being a superclass of Monad in the language, when it mathematically should be. This should be fixed in Haskell 2014, though.
Re: Please reconsider the Boolean evaluation of midnight
#136Re: Please reconsider the Boolean evaluation of midnight
#137Earlier quoted context omitted.
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.
Linus does NOT break backwards compatibility. That is what this change implies. Which doesn't mean I disagree with changing the behaviour, but I doubt Linus would use that reason for that.
It's undocummented, and very complex to use. That mail does not even have sufficient information to understand how to use this "feature". I hightly doubt anybody uses it outside of the datetime codebase.
I never saw Linus complaining about changing undocummented and not used behaviour.
Re: Please reconsider the Boolean evaluation of midnight
#138Earlier quoted context omitted.
Linus does NOT break backwards compatibility. That is what this change implies. Which doesn't mean I disagree with changing the behaviour, but I doubt Linus would use that reason for that.
It's undocummented, and very complex to use. That mail does not even have sufficient information to understand how to use this "feature". I hightly doubt anybody uses it outside of the datetime codebase. I never saw Linus complaining about changing undocummented and not used behaviour.
It is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.
Re: Please reconsider the Boolean evaluation of midnight
#139Earlier quoted context omitted.
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…
Indeed, the first thing that came into my mind when reading this was "You wouldn't have this problem if the only valid type in a conditional was boolean."
The first thing that came into my mind when reading this was "You are a fool of a great intelligence."
Re: Please reconsider the Boolean evaluation of midnight
#140INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...
Abelian group is a sort of stringent requirement, they probably just mean a plain monoid? After all it works for python lists, which form a non-commutative monoid:
[] + [] == []
[1,2] + [3] != [3] + [1,2]