Wow, all these years and I never knew an empty list was false-y. I guess I've always done if len(foo) > 0:. Personally I don't think I'd use those types of checks since it's ambiguous what's being...
Wow, all these years and I never knew an empty list was false-y. I guess I've always done if len(foo) > 0:. Personally I don't think I'd use those types of checks since it's ambiguous what's being tested.
I also use if x is None: rather than just if x for an Optional.
Writing checks like that generally isn't considered "Pythonic", and PEP8 specifically says to use if foo: over things like if len(foo) > 0:. Pylint will throw an error complaining about it if you...
Writing checks like that generally isn't considered "Pythonic", and PEP8 specifically says to use if foo: over things like if len(foo) > 0:. Pylint will throw an error complaining about it if you do it:
pylint: len-as-condition / Do not use `len(SEQUENCE)` to determine if a sequence is empty (col 11)
Good to know. I don't I'll change my ways, though. It just seems like a bad design choice to have an operation perform so many different things. Imagine if someone wrote a function like that. def...
Good to know. I don't I'll change my ways, though. It just seems like a bad design choice to have an operation perform so many different things. Imagine if someone wrote a function like that.
defis_truthy(x):ifxisNone:returnFalseifisinstance(x,bool):returnxifisinstance(x,list):returnlen(x)>0# Many other checks# ...returnTrue
The function makes it harder to read code. I think the best thing Python does as a programming language is make code read like plain English. But we need precision when reading code to understand what's going to happen once the bits hit the interpreter (and not just once the code is written, but also a year down the road).
To be fair part of my perception of this being less readable is due to my ignorance of the length check until now. But it still feels icky and I've usually avoided "truthiness" in every language that uses it.
Sorry, should be fixed now.
Maybe unnecessarily, I created an issue for it.. I was just curious what could break the site for only those two posts.
It was just any topic with zero comments.
Cool, thanks. I see the commit now.
@Deimos, if
self.treecan beNone, shouldn't it be defined asOptional[List[Comment]]?It's never
None.if self.treewon't be satisfied by an empty list.Wow, all these years and I never knew an empty list was false-y. I guess I've always done
if len(foo) > 0:. Personally I don't think I'd use those types of checks since it's ambiguous what's being tested.I also use
if x is None:rather than justif xfor anOptional.Writing checks like that generally isn't considered "Pythonic", and PEP8 specifically says to use
if foo:over things likeif len(foo) > 0:. Pylint will throw an error complaining about it if you do it:Good to know. I don't I'll change my ways, though. It just seems like a bad design choice to have an operation perform so many different things. Imagine if someone wrote a function like that.
The function makes it harder to read code. I think the best thing Python does as a programming language is make code read like plain English. But we need precision when reading code to understand what's going to happen once the bits hit the interpreter (and not just once the code is written, but also a year down the road).
To be fair part of my perception of this being less readable is due to my ignorance of the length check until now. But it still feels icky and I've usually avoided "truthiness" in every language that uses it.