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

[Steven D'Aprano]

On Tuesday 01 December 2015 16:54, Rick Johnson wrote:

> On Monday, November 30, 2015 at 7:01:14 PM UTC-6, Steven D'Aprano wrote:
>> I'm trying to understand why vars() exists. Does anyone use it?
> 
> I think your "mental dilemma" stems from the fact that python was
> originally created to be an easy language for noobs to learn (which it
> still mostly is), 

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.


> however, over the years, feature creep has expanded this
> small general purpose language to include many specific applications. The
> "vars" function is a relic of the early days of Python and has not evolved
> because 99% of Python hackers find it to be useless. I mean, heck, print
> did not evolve until Py3! Outside of a few test sessions in my early days
> with Python, I don't remember ever using the vars function again.
> 
> Your lament does remind me of a pet peeve i have concerning Python, and
> that is, the lie about: "THERE SHOULD BE ONE (AND PREFERABLY ONLY ONE) WAY
> TO DO IT!". In fact, in python there is almost always *MANY* ways to
> achieve the same output.

You misunderstand the koan.

"There should be one way to do it" does not prohibit more than one way. 
(Although having multiple redundant ways is discouraged.) The koan exists to 
encourage the existence of *at least* one (but preferably only one) way to 
do it.

"It", of course, is not defined, as if fitting for a koan. (Koans are meant 
to make you think, and they also act as a way of separating the adults from 
the kiddies -- do you have the experience to grok the meaning of the koan?

For example, some people have been fooled by the apparent similarity of 
globals(), locals(), dir(), __dict__ and vars(), thinking that this is five 
ways to do the same thing, right? But no.

(1) globals() *always* returns the global namespace.

(2) locals() *always* returns the local namespace. It just happens that 
sometimes the local and global namespaces are the same.

(3) dir() is intended as a user-friendly introspection tool at the 
interactive interpreter. As a result, it is permitted to modify the list of 
names returned, and in fact it does, suppressing some names which the core 
developers deem insufficiently "interesting".

(4) __dict__ (in the sense of obj.__dict__) is the implementation, not part 
of Python's high-level interface. Attributes have to be stored somewhere, 
and Python chooses to reveal that in the documentation, nevertheless if you 
find yourself writing "__dict__" in production code, you're probably doing 
something wrong.


These three functions, and one attribute, are clearly related, but they are 
just as clearly solutions to four distinct problems. There may be a little 
overlap, but at their core, the "it" that they are the way to "do it" are 
very different things.

Which brings us to #5, vars():

"What is vars() good for?" is exactly what I'm asking. It seems to be the 
high-level interface to the implementation detail of __dict__, but I'm not 
sure that's needed. When that implementation changes -- classes using 
__slots__ instead of a dictionary -- we should expect that the high-level 
interface should adapt, otherwise what's the point of it? But it doesn't.

vars() also defaults to returning locals() for no good reason I can see. 
Whatever the "it" is that vars() is meant to do is a good question, but it 
clearly isn't the same "it" as that for globals(), locals() and dir().


> We may find this difficult to believe, but many a noob has been stumped by
> the following questions:
> 
> (1) How do you output a message without the print function?

*scratches head*

Why would you want to do that? print is clearly the "one obvious way" to 
output a message.



-- 
Steve