Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
If the if statement can evaluate foo() as a Boolean 9 times out of 10 you can assume that it is one.
-
spl020438y@Romulus10 well in python... for example, you could return 1 or 0. Thats not a boolean, but 'if' would still treat it as one....
-
In that case, this code could still be avoided. foo() could return directly to the target and would evaluate the same as if this code returned true or not.
-
spl020438y@Romulus10 Yes but its an int. Just because if makes something of it, doesnt mean you can assume its a boolean!
-
Yeah, that assumption could probably end up not being the best practice. In most cases, though, I would probably leave this bit out.
-
From where I'm looking at it, leaving out the conditional will make the common case faster.
-
spl020438y@Romulus10 I think lig's return bool(foo()) is probably the best unless we know foo() returns boolean, in which case just return foo()?
-
I wonder why (out of context of course) we couldn't skip the return statement and just call foo() from where we need it returned to.
-
spl020438y@Romulus10 Because (in theory) we dont know whats before this code in the same function....
-
Yeah, that's why I said out of context. The fact that there are no arguments to foo() makes me think it should be safe but there's always the possibility.
Related Rants
Yet again
If foo():
return True
else:
return False
Agrrr!!11
undefined
python
juniors at work