> > It's not picking up that *location* has changed. It just keeps repeating the original location description.
>
> Hrm. That's probably because it's using a local "location" variable that is different from the real thing. I'm just guessing. To understand this, you need to learn about scoping and namespaces, which is a pretty hefty topic if you're not already familiar with the concept from other programming languages. Essentially, the idea is, if you have a variable x in one function, it's not the same physical variable as the variable x in another function. And some variables are "global," meaning that they can be accessed from within ANY function in the module, and so a global variable x is yet a third distinct physical variable.
>
> The way all these variables named 'x' are distinguished is through namespaces. Each function gets a namespace. All globals go in their own namespaces. You can't have more than one variable 'x' in the same namespace. So if you see a variable name in code, the question you ask yourself is, which namespace is it in? The "local" namespace refers to the namespace associated with the function that you're in.
>
> In my snippet of code, my intention was to have the "location" variable be in the global namespace, so that all functions use it. But I suspect I screwed up, and instead I've got one "location" variable in the namespaces of each of the functions that "location" variable appears in. Consequently, changing one of them does not change the others.
>
> If you can wade through http://python.org/doc/current/tut/node11.html#SECTION0011200000000000000000 , which discusses scoping rules and namespaces in Python, then you are sharp indeed, and you'll probably know all you need to know about handling namespaces.
>
> The short answer, however, is that putting the line:
>
> global(location)
>
> ...at the beginning of each function that uses the "location" variable will probably solve the problem. *IF* I diagnosed the bug correctly in the first place.
>
> If that is the case, you'll probably need to make 'inventory' a global as well.
>
> Rather than having all kinds of globals, though, you might do better to use a class instead. If you understand classes from the tutorial (http://python.org/doc/current/tut/node11.html), then I'd suggest having a "PlayerState" class, which contains all the variables about where the player is in the game. Each class, you see, is its own namespace, and if you plug all your state-of-the-game variables into one class, you can create an instance of PlayerState and use that. Then you don't have to global(...) everything.
>
> And if that last paragraph was too much to comprehend, forget about it for now and continue trying to learn Python from wherever you left off in the tutorial.

Thanks, I understand the concept. I'll research it more.

Thanks again!!!
~Angela