integer >= 1 == True and integer.0 == False is bad, bad, bad!!!
in [Python]
|
Prev: grailbrowser now running under python 2.5 (probably above too)
Next: Naming Conventions, Where's the Convention Waldo?
From: Paul Rubin on 12 Jul 2010 20:36 Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > This is why virtually all low-level languages treat 0 as a false ... OK, but is Python a low-level language, and if not, why are low-level languages appropriate examples to follow? >> if myInt <> 0: > > I would argue against that. Why do you, the coder, care about the > specific details of treating ints in a boolean context? The int type > itself knows, leave the decision to it. There is a horrible (IMO) thing that Perl, Lua, and Javascript all do, which is automatically convert strings to numbers, so "12"+3 = 15. Python has the good sense to throw a type error if you attempt such an addition, but it goes and converts various types to bool automatically, which is more Perl-like than I really enjoy. In fact Python 3 added yet another automatic conversion, of int to float on division, so 1/2 = 0.5. Obviously it's a point in the design space where various decisions are possible, but I can get behind the "explicit is better than implicit" idea and say that none of those conversions should be automatic, and if 1/2 = 0 was confusing people in Python 2 enough to justify changing divison semantics in Python 3, the preferable change would be for int division to raise TypeError rather than quietly converting to float. The same thing goes for bool conversion, though we are all used to it by now, and it would be way too disruptive a change. > if myValue.count <= 0 and myValue.next is None and myValue.blob == "": > # myValue is considered false > versus: > if not myValue: > Which would you prefer? I'd personally prefer if not bool(myValue): which would call the myValue's __bool__ method if it chose to implement one. Explicit is better than implicit.
From: Ian Kelly on 12 Jul 2010 21:28 On Mon, Jul 12, 2010 at 6:18 PM, Steven D'Aprano <steve(a)remove-this-cybersource.com.au> wrote: >> I prefere to explicitly write what I want to test: >> >> if myInt <> 0: > > I would argue against that. Why do you, the coder, care about the > specific details of treating ints in a boolean context? The int type > itself knows, leave the decision to it. I think you're missing the point. He's not using ints in a boolean context. If it were a boolean context, he would be using bools in the first place. What he is objecting to is the practice of testing for special cases of ints (i.e. 0) by treating them as bools. The specific details of converting ints to bools are very much relevant here; as long as 0 is false, it works. If -1 is false (a semantic I have actually seen used), then it does not. Cheers, Ian
From: Ian Kelly on 12 Jul 2010 21:41 On Mon, Jul 12, 2010 at 6:36 PM, Paul Rubin <no.email(a)nospam.invalid> wrote: > There is a horrible (IMO) thing that Perl, Lua, and Javascript all do, > which is automatically convert strings to numbers, so "12"+3 = 15. > Python has the good sense to throw a type error if you attempt such an > addition, but it goes and converts various types to bool automatically, > which is more Perl-like than I really enjoy. In fact Python 3 added yet > another automatic conversion, of int to float on division, so 1/2 = 0.5.. > > Obviously it's a point in the design space where various decisions are > possible, but I can get behind the "explicit is better than implicit" > idea and say that none of those conversions should be automatic, and if > 1/2 = 0 was confusing people in Python 2 enough to justify changing > divison semantics in Python 3, the preferable change would be for int > division to raise TypeError rather than quietly converting to float. I don't think it's any more egregious than automatic conversions of mixed-type expressions, such as 3 + 4.5. If you don't want your ints automatically converted to floats on division, then use the integer division operator. 1 // 2 is still 0 in Python 3. Cheers, Ian
From: Paul Rubin on 12 Jul 2010 22:14 Ian Kelly <ian.g.kelly(a)gmail.com> writes: > I don't think it's any more egregious than automatic conversions of > mixed-type expressions, such as 3 + 4.5. That could also be explicit: float(3) + 4.5, or 3 + int(4.5). > If you don't want your ints automatically converted to floats on > division, then use the integer division operator. 1 // 2 is still 0 > in Python 3. Sure, I do that, but the issue was that 1/2 was confusing newbies who don't understand the different characteristics of int and floating types. If the idea is to change Python to fix this problem in a newbie-friendly way, the right fix is to create enlightment by raising an exception that points out the problem, not sweep it under the rug with an automatic conversion.
From: Cameron Simpson on 12 Jul 2010 22:30
On 12Jul2010 17:36, Paul Rubin <no.email(a)nospam.invalid> wrote: | Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: | > This is why virtually all low-level languages treat 0 as a false ... | | OK, but is Python a low-level language, Not particularly, but true/false and Boolean login are low level ideas. If it works well in a low level language (where all you might have are ints of various flavours and thus some equivalence notion is required), why would you _change_ the conventions in a high level language without a compelling reason? The more commonality in concepts there are, for all that they are just conventions, the easier it is remember how to do things. | and if not, why are low-level | languages appropriate examples to follow? They may not be in any inherent sense, but they are examples and if the usage doesn't cause pain are they inappropriate? Steven: | >> if myInt <> 0: | > | > I would argue against that. Why do you, the coder, care about the | > specific details of treating ints in a boolean context? The int type | > itself knows, leave the decision to it. [...snip...] This I'm only halfway with. I, the coder, _must_ know. The "if" statement has an intent, and I need to know that "if myInt:" matches my intent. Of course, using the right idioms it will match a lot of the time. But I've certainly been bitten by writing: if myDict: intending: if myDict is not None: but also getting: if myDict != {}: Clearly the fault was mine, but I, the coder, _must_ care about the details of using non-Booleans in a Boolean context. Cheers, -- Cameron Simpson <cs(a)zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ It is Texas law that when two trains meet each other at a railroad crossing, each shall come to a full stop, and neither shall proceed until the other has gone. |