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.
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
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.
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.
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
varmust 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.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
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.
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.