I'd argue that if it's strict explicitness you want, python is the wrong language. if not var is a standard pattern in python. You would be making your code slower for no good reason.

[–] [email protected] 11 points 1 day ago (8 children)

You always want explicitness when programming. Not everyone reading your code will be deep into Python and relying on falsiness makes it harder to understand.

[–] fruitcantfly 2 points 23 hours ago (1 children)

Containers being "truthy" is quite basic Python and you will find this idiom used in nearly every Python code base in my experience

[–] [email protected] 3 points 23 hours ago* (last edited 23 hours ago) (1 children)

Yeah, I'm talking less deep than that. Plenty programming beginners will be reading Python code. And personally, I'm a fulltime software engineer, but just don't do much Python, so while I had it in the back of my mind that Python does truthiness, I would have still thought that var must be a boolean, because it's being negated. Obviously, a different variable name might've given me more of a clue, but it really doesn't reduce mental complexity when I can't be sure what's actually in a variable.

[–] fruitcantfly 1 points 22 hours ago* (last edited 22 hours ago) (2 children)

But if those beginners want to stop being beginners, then they must learn the basics of the language. It makes no more sense to demand that everyone who programs in Python caters to beginners, than it makes to demand that everyone writing in English write at a 3rd grade reading level for the sake of English language learners

[–] [email protected] 4 points 20 hours ago

I think you just like the truth test. Frankly I have used Python for over 25 years and have been doing programming for almost 50 years in many different languages. If you think I am somehow a beginner, I would disagree. The truth test is just like so many other Python specific idioms that grow in number by the year. They are not at all obvious unless you are deep into Python. Moreover, the truth test and the len() test are not the same test. One might be able to use either in a specific case, but that is case specific and which is more readable is up to the developer and we may well disagree on that choice. The other consideration in Python, speed of writing code which is often why many of us use Python and that may lead to different choices too including based on habit.

Lot of this reminds me of the Pascal vs. C debate of the 1980's. Pascal was all about readability over compactness. C on the other hand, seemed to attract people that loved to write very compact code that was almost impossible to figure out on first glance. Me personally, I guess I'd choose C over Pascal but write the C in more of a Pascal authoring philosophy. Similarly, with Python, I often do not go for all of the Python idioms. Lot of that is just writing what I am thinking, and the rest is probably habit. If I am going to test 0 length then I'll probably test zero length. I do not find it at all obvious that, oh, I want to test 0 length so the Python idiom for that is to truth test. I absolutely know that to be the case on certain types of objects, but it probably is not going to be my first choice.

[–] [email protected] 3 points 22 hours ago

Yeah, my stance for both of those is the same: If the complexity aids you in communicating better, then use it. But if you're using big words where small words would do, then you're doing a disservice to your readers.

load more comments (6 replies)

load more comments (19 replies)