151–160 of 218 posts
Earlier quoted context omitted.
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."
INADA 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...
Came here to say this. It's the most useful statement in the entire thread of "you're wrong!" "no, you're wrong!" and nobody noticed.
INADA 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...
This is a nice clean criterion, but it's still pretty unclear to me why the zero element of a monoid should be considered falsey at all.
if x:
else:
return
INADA 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...
If that were true, it would mean that dict should not support bool: >>> {} + {} Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'dict' and 'dict' >>> bool({}) False Since I find bool(a_dict) to be very useful, and the lack of a_dict+b_dict to be reasonable (precisely because it's non-abelian!), I conclude that logic is cute, but not that relevant. Those who think…
I think the interesting part is what is revealed about Python and the difference with something like Ruby. Python is stable[0] and places a high degree of importance on backwards compatibility. This behaviour is well documented (and called out for particular note). This reinforces that it is (a) official and (b) not a bug because it is the documented behaviour. On the other hand Ruby (and most Ruby libraries) seem bo…
I'm gonna disagree with you! Well, I actually agree about ruby libraries , but the ruby standard library is the proper comparison here, which in my experience manages backwards compatibility and documentation of edge cases rather nicely. The (many) changes to the language itself since 1.8 have nearly all happened in backwards-compatible ways. So maybe the ruby community has a more flexible attitude (I've honestly nev…
Earlier quoted context omitted.
If that were true, it would mean that dict should not support bool: >>> {} + {} Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'dict' and 'dict' >>> bool({}) False Since I find bool(a_dict) to be very useful, and the lack of a_dict+b_dict to be reasonable (precisely because it's non-abelian!), I conclude that logic is cute, but not that relevant. Those who think…
{1: ["A", "B"]}?
Earlier quoted context omitted.
If that were true, it would mean that dict should not support bool: >>> {} + {} Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'dict' and 'dict' >>> bool({}) False Since I find bool(a_dict) to be very useful, and the lack of a_dict+b_dict to be reasonable (precisely because it's non-abelian!), I conclude that logic is cute, but not that relevant. Those who think…
{1: ["A", "B"]}?
{1: "A"} + {}
What about
{1: "A"} + {} + {1: "B", 2: "Z"} + {1: "C"} + {}
Guido chose the current behavior because there is no clear-cut winner. "Refuse the temptation to guess."
Everyone is talking higher echelons of consideration, but what effect is there on generated byte code or in fitting within the virtual machine's tight pants?
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.
Ignoring Python for a bit and thinking as a designer of some hypothetical future language: there is a nice rule given here for evaluation in a Boolean context. I wonder whether it should be taken as a general guideline for future languages. The rule, in its entirety, is this: - Booleans are falsy when false. - Numbers are falsy when zero. - Containers are falsy when empty. - None is always falsy. - No other type of v…
Making anything besides booleans "truthy" strikes me as asking for a lot of trouble for very little gain. For each of these cases, how hard is this to write: x == 0 isempty(x) x == nothing How much clearer is the intent of that code than a truthy boolean test would be? This clarity is all the more important in dynamically typed languages without type annotations since the code itself doesn't give any hint what the ty…
E.g. you can't say following in C#
if(number) //number is of type integer.
if(o1) //o1 is a reference type variable.
if("string")
if(number = 10) // number = 10 is an assignment and produces 10.
You must write:
if(number == 0)
if(o1 != null)
if("string".Length > 0)
if(number == 10)