Skip to main content

Dynamic Hell in Python Names

There is a question I often see from Python newbies: How to use the contents of a string as a variable name. In other words, to dynamically create a variable based on some runtime-found name. A lot of these users come from more static backgrounds and have heard the benefits of dynamic languages. I have to wonder if these are signs of their over-eagerness to exploit that dynamic nature.

exec "%s = %d" % (raw_input(), input())
Example of dynamic variable names in action. To a pythoner, obviously not pythonic.

d = {}
d[raw_input()] = int(raw_input())
Less bad. This is why dictionaries exist, so we use them. Also, we remove the potentially dangerous and frivolous use of input() in favor of int(raw_input()).

There are a lot of things that different programming languages are good for and things they are bad for. There are times when their negative points can be exploited, of course. There are far more times when their positive points can be exploited, and turned into disaster. Pointers in C, for example, are useful in the cases where they are used properly and smartly, but terrible when wielded by the wrong hand with evil or ignorant intent. The same can be true for a lot of a dynamic language's features.

People trying to avoid knowing the names and number of variables they have, create classes on the fly with runtime information, and build and evaluate python code in strings are looking at the flexibility of the language and really want to use that for their own good. The problem is that great power requires great responsibility, as we all know. What most of us don't realize, is that great responsibility requires great wisdom, and we can't buy, read, or request on IRC for wisdom. That means the great power that lures these new comers to the language is inevitably what will always keep them from fully experiencing the gifts it bestows. This is not a flaw or a unique attribute of the language, of any language, or of anything at all which benefits mankind and requires knowledge. Just don't exert yourself. Don't do anything for the sake of paradigms or languages or buzzwords. Solutions are neutral, so solve them for solution's sake, not implementation's sake.

[foo() for i in range(10)]
An obvious abuse of a list comprehension as a for loop one-liner. (We know this, because the resulting list is thrown away.)

What I find the most odd is the reactions these individuals give when you tell them what they are doing wrong, and what to do instead. If they want dynamic variable names, we tell them to use a dictionary; they complain about the inefficiency of hash table lookups versus variable names (from a C perspective, often). The simple thing I cannot understand with this is how they expect the dynamic variables work, if not a hash table. If they think they work like C stack locals, yet can be dynamic, why would they think that magical technique would not be applied to dictionaries. In other words, if they recognize they achieve the same end, why do they think they are such wildly different routes?

Update: I added some examples the day after initially posting this.


Unknown said…
this entries need examples. I think I agree with you but you need to be more specific.

Generalities won't help newbies understand your point, old-timers understand but do not need them.

As bonus, some specific examples could foster some thinking (we are all part newbies).
Anonymous said…
You know, back when I started into programming I found I wanted (although i wasn't sure why) to be able to be able to create variable names programaticaly. Later I found, that if i kept an array of values and a syncronized array of names i could get close to what i wanted. Then i found associative arrays in php, and haven't looked back.

Basically it all boils down to the need for dicts. A data structure we all feel the need for, instinctively.

But as you said, some people from the static camp can't see why what they want is a dictionary.
Yoni Samlan said…
reminds me of what happens when people try to use what they know from Java to write Python, only from a C perspective. The classic blog entry on the topic: python is not java

One of the commenters made me think of this part of it:

"Got a switch statement? The Python translation is a hash table, not a bunch of if-then statments. Got a bunch of if-then's that wouldn't be a switch statement in Java because strings are involved? It's still a hash table. The CPython dictionary implementation uses one of the most highly-tuned hashtable implementations in the known universe. No code that you write yourself is going to work better, unless you're the genetically-enhanced love child of Guido, Tim Peters, and Raymond Hettinger."
Doug Napoleone said…
Whenever one of the researchers asks me about doing this instead of using a dictionary, I show them the globlas() and locals() commands which return the dictionaries for the respective closures. "See it's a dictionary, and this specific dictionary, have fun."
Anonymous said…
Had an interview for a Python job. It wasn't deep Python but the first technical question the interviewer asked was "what's a dictionary?"

I suspect if I hadn't known the answer the interview would have been quite short.

A friend teaches computer science. He is appalled when seniors and even masters students come into his classes with zero understanding of dictionaries, also known as hashes, also known as associative arrays.

If you don't use them, it's a good guarantee your code will be obscure, and very likely at least one power of N too slow.
Albert said…
Too right! Dynamic languages like Python and PHP lead to nothing but trouble.

On a related note, even C# has adapted some aspects of dynamic languages - the "var" keyword. I'm currently in an "argument" with some colleagues about disallowing it in production code, but I'm meeting heavy resistance. Do you have any good arguments I can use?
Calvin Spealman said…
Albert, I am a Python developer and wouldn't change that. I'm only advocating that whatever kind of code you are doing, you do it right.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

The Range of Content on Planet Python

I've gotten a number of requests lately to contribute only Python related material to the Planet Python feeds and to be honest these requests have both surprised and insulted me, but they've continued. I am pretty sure they've come from a very small number of people, but they have become consistent. This is probably because of my current habit of writing about NaNoWriMo every day and those who aren't interested not looking forward to having the rest of the month reading about my novel. Planet Python will be getting a feed of only relevant posts in the future, but I'm going to be honest: I am kind of upset about it. I don't care if anyone thinks it is unreasonable of me to be upset about it, because the truth is Planet Python means something to me. It was probably the first thing I did that I considered "being part of the community" when I submitted my meager RSS feed to be added some seven years ago. My blog and my name on the list of authors at Plan

Pythonic Defined

Introduction Losing is Good Strings Dictionaries Conclusion Introduction Veterans and novices alike of Python will hear the term "pythonic" thrown around, and even a number of the veterans don't know what it means. There are times I do not know what it means, but that doesn't mean I can define a pretty good idea of what "pythonic" really means. Now, it has been defined at times as being whatever the BDFL decides, but we'll pull that out of the picture. I want to talk about what the word means for us today, and how it applied to what we do in the real world. Languages have their strengths and their idioms (ways of doing things), and when you exploit those you embrace the heart of that language. You can often tell when a programmer writing in one language is actually more comfortable with another, because the code they right is telltale of the other language. Java developers are notorious for writing Java in every language they get their hands on. Ho