Is vars() the most useless Python built-in ever?

[Rick Johnson]

On Tuesday, December 1, 2015 at 1:55:59 AM UTC-6, Steven D'Aprano wrote:
> Python was never intended to be "merely" a teaching language. I think 
> Guido's original vision was for it to be a glue language between C 
> libraries, and a scripting language.

It's a well know fact that GvR was inspired to create Python from his experiences working with a language called ABC -- and ABC was designed *EXCLUSIVELY* to be a beginners language. GvR has even written that one of his objections to ABC's design was it's tendency to create new jargon-isms to replace old jargon-isms. The language designers "thought" they could ease the learning curve simply thru virtue of symbols, but all they did was to further confuse noobs. GvR saw the folly of this, and set out to prevent such design flaws in his language, however, i argue that interfaces like the "print function" are making the same mistakes. The linking of abstraction layers  is even *MORE* important than intuitive naming conventions. But sometimes the name is the only path by which you can provide the link. As is the case with the print function.

> > Rick said:
> > (1) How do you output a message without the print function?
> 
Steven said:
> *scratches head*
> 
> Why would you want to do that? print is clearly the "one obvious way" to 
> output a message.

Well of course the answers are *OBVIOUS* when you already *KNOW* them Steven! Climb down off your high horse for a moment, and take yourself back to a time *BEFORE* you had any knowledge of output streams. 

I am not arguing that "abstractions are evil", no, my position is that abstractions must be constructed in a manner that provides a clear trail of bread crumbs which lead to the underlying processes. With print, not only is the engine in another dimension, but the hood is as well! How is a noob to discover the engine when he cannot find the hood?

Ponder the following example code (as a noob!):

 stdout.write("Dude, i found my car, the hood, and the effing engine!!!")

Even a noob can intuit what is going on here. First we have an *OBJECT* named "stdout, and we can extrapolate that stdout is an abbreviation for StandardOutput. Next, we see a method called "write", and, if our IQ is above room temperature, then we can extrapolate what that method will do.

Now ponder this code (as a noob!):

 print("Dude, where's the intuitiveness?")

What the heck does print do? Where will the string go after i execute this line of code? Should i turn my printer on? Should i check my ink levels? And what OEM drivers are required?

Not only is "print" un-intuitive (by nature of it's naming), it is obfuscating the path to the underlying process of "sending data to an output stream".