I am having a bit of a problem with nosetests on this exercise. I have written and rewritten the code (compared it to yours obsessively). Understood the structure of the directories and done all the import statements, as well as prerequisite pip package installations but I keep getting a very strange syntax error. I hope you can help because I’ve been slowly going crazy. Please note the error in the bash session
Hello everyone,
Hi Kila,
You need to use { } instead of [ ] when playing with dictionaries.
You use [ ] for lists.
Hope this helps.
1 Like
Thanks, this was super helpful!
1 Like
Hey @kila, in your copy of the book do you have [] instead of {}? Was it a printed copy? I ask because the publisher messed up those characters in all dictionaries and some copies still have that.
Hey @zedshaw, it is an e-book. The current solution that I’m using involves commenting out select assert_equal statements as illustrated in the attached screenshot.
I believe it’s assert_equals @kila, not assert_equal. Try that, and if that doesn’t work try the newer eq_ instead, as mentioned here http://nose.readthedocs.io/en/latest/testing_tools.html#nose.tools.eq_
I changed that and this is what happens. I am currently reading up the eq_ tool and will test the code with that. Thanks for the link 
Ok, this is progress. But now you have to read the error message more closely. Do you see how it’s not complaining about assert_equals anymore, but about how you are using go()? It says go takes 3 arguments but you’re giving it two arguments. That means you have an error in your Room.go code, most likely to do with not having self as a parameter, and I cover that in the video I believe.
I’ll also point out a classic mistake you’re making that everyone makes–professional or beginner:
You assume, that if there’s an error, then it can’t be in what you wrote, it must be “something else”. It can’t be that you spelled assert_equals wrong, or what you wrote for go is wrong. I must be some mysterious thing hiding in the machine, and that what you wrote has to be right.
After many years of thinking that way, I now think this way:
If there’s any error it’s always something I wrote, and the error is in the code. There is always an explanation and there is no magic or mystery to it, I just don’t have enough information. When I’m done writing code, I always assume it’s wrong and I review it before I run it because I know it’s probably wrong.
Take a break from this for a day, and then see if you can’t change your thinking about this to be more like mine. Don’t just comment something out and go “ok now it works”. Find out why commenting that out worked and fix it. Don’t assume that an error is somewhere magical, actually spend the time to find out more information and look in places other than where the error message is. For example, in this error, the error is not on that line, it’s in a whole other file. Start looking everywhere that you haven’t looked yet.
1 Like
Okay, thank you. I’ll look into that and use the guidelines you’ve stated.
I actually just fixed it! It was a sloppy mistake on my game.py file in an adjacent directory. Thank you for your help @zedshaw. I really appreciate it. On to the next exercise!
I also do quite a bit of FP in Scala for building WSNs which involves a totally different paradigm and whose syntactic composition and constructs are galaxies away from Python. I’ve only been coding for a bit over a year now. Any more nuggets of wisdom you would like to offer about adopting systems thinking and becoming a better developer would be truly appreciated.
The biggest advice is to assume you know nothing about a new language, even though you already know another language. What happens is people learn a first language, and then that becomes some kind of truth about how programming is done. They then take that truth and try to apply it to a new language, with expectations that this new language will work the same, and it leads to trouble.
The reality is, these languages are all social constructs that have no truth outside of their little worlds. You can think of it like driving in different countries. Some countries are on the left, others on the right. If an American shows up in the UK and just decides that she’ll drive on the right because that’s the truth, she’ll get into trouble. The smart person shows up and finds out what side of the road is used in that country and then just drives there, since the choice is just arbitrary anyway.
In your case, you learned more FP, but Python is fairly lackluster when it comes to FP. It has list comprehensions and that’s kind of it. Don’t try to do recursion as Python’s recursion doesn’t have tail calls so it’ll crash. You should approach Python as if you know nothing, and don’t assume that the way it’s done is “wrong”, just accept that it’s different.
2 Likes
In this exercise under the study drills it is mentioned that make the room more advanced and rebuild your game and I have no idea how I am gonna do that.
looking for help…
Thank you
Alright, first remove all of the content from my game code. Strip it down so that it’s lost all of the text and you just have the code structure, maybe with little place holders for room like “ROOM A”.
Now, map out my rooms and such so that you know where everything is.
Then, go in and write your own story for the rooms. Come up with anything, but keep the same rooms, just add your own text.
Make that work, then start thinking about what your rooms need to be good. Do you need some kind of monsters? Better combat? Then write a description of what those are, and try to make it happen by changing my rooms.
Keep doing that until you get bored. Or, skip that idea and just go on to another book that covers a topic that interests you.