The issue I take with the pythonic style of variable/method/object naming is that such a style conflicts with how the brain works. When you read, you don’t read letters, you read a block of squiggles that together represent words. When you read the word “dog”, your brain doesn’t concentrate on the d or the o or the g. It actually pattern matches on the combination of letters, the whole word. And what separates these blocks of squiggles are open areas between word patterns, namely, spaces. Spaces are the visual cues that your brain uses to separate word patterns. Now when you read the word dogfood, your brain initially identifies that this new pattern is a contraction of two patterns. But in future reading of that same pattern, dogfood, your brain will see that pattern as a single representational entity.
If you, on the other hand, were to divide those two patterns by a space
“dog food” your brain will continue to see them as two separate patterns. I hold that the underscore is an equivalent replacement for the space. That the variable name “dog_food” remains as TWO words. And that being two words your brain must do extra duty to identify this as a SINGLE thing.
DogFoodWithGravy — can be interpreted, by your brain, as a single entity.
dog_food_with_gravy — will ALWAYS be interpreted as four separate words that your brain must parse EVERY TIME you read it.
This, this is the primary reason that pythonic naming is a failed style.
One thought on “Python naming – a broken style”
I find that both R and Python are intentionally cryptic. How often I’ve been derided for my verbose re-interpretation of methods and function in both languages I can’t tell, but it had been constant. The ongoing challenge, by the “wizards” I worked with, was to produce the tightest, most nested code, with the fewest lines — but with readability and mental checks for correctness thrown out the window.
Data science teaching, to me, should start with SQL and Excel. See the data, touch the data, coalesce and group and distill and cross-tab the data. And when you’ve exhausted those data interrogation venues (and I’ll admit they get exhausted pretty quickly once you’ve mastered them), then move on to the cryptic languages: R and Python, Scala or F#.
Starting out with cryptic languages forces the learner to forego focusing on the data, modeling it, extracting meaning and hopefully knowledge from it, and instead, waste hours and days and weeks struggling with languages intentionally designed to be hard to linguistically fathom.