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 -- https://mail.python.org/mailman/listinfo/python-list
