EX 15 Study Drills #4 - Learn Python3 the Hard Way


#1

I am totally lost on the next four questions in Study Drills for EX15 in Learn Python 3 the Hard Way.

#4 - Do I get rid of all lines between ##10-15, or only those lines in that section that contain the input() function?

#5 - Use only input and try the script that way. I am not sure what you mean by “only input()” “only input() as opposed to what?” I am not sure what your unsaid text is.

#5 - Why is one way of getting the filename better than another? I have no idea what this is about.

#6 - Start python 3.6 (3.7) to start python 3.6 shell. Here is what I get when I try to run open()function
Last login: Sun Mar 31 09:59:56 on ttys003
Lowells-MBP:~ lowellcopeland$ python3
Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43)
[Clang 6.0 (clang-600.0.57)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
>>> open(ex15_sample.txt)
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
NameError: name ‘ex15_sample’ is not defined
>>>

#7 - print(txt.close())
#7 - print(txt_again.close())
none
none


#2

Hi @LowellCope

In this lesson there is two ways to open that text file.

The first time it is opened it got the filename when you run your code:

python3 ex15.py sample.txt

the second time it call for a text file to open its the input function inside your code

file_again = input('>: ')

Here you type in the same file name for the text file (sample.txt).

#4
You have to comment out all of those lines. They all belongs to the second part (open file_again).

#5
If you comment out the first 8 lines of code you only do the input part.
Then you don’t add the txt file after python when you run the code

python3 ex15.py 

#6 First. You forgot the " " around the filename.
Has to be like: open(‘sample.txt’)
Second. You need to attach this to a variable.

text_content =  open('sample.txt')

#7
You just have do type:
txt.close()
file_again.close()


#3

Hi Ulfen69
Thank you so much for your help on the questions I submitted. Your answer on #7 was absolutely correct . Thanks. I realized after reading your answer on question #5 that the solution was pretty simple. I went back and listened to the video for exercise 14 and Zed made it clear that for the purposes of getting input into a script, using command line arguments with argv is better than using the input() function because most users don’t like prompts in their programs and 98% of the command line tools use the argv method.

I tried commenting out lines 10,11,12, 13, 14, and 15. The program ran fine. Thanks

Sometimes I find that I have to wait a day or two and let things sink into my brain. It might have been better if I had done that this time. I really appreciate your help.

Sincerely,

LowellCope


#4

I think this points to a piece of advice I have for people:

Most of your education experience is probably one where, when you ran into trouble, you just ran to a teacher or helper rather than solving it yourself. Problem with is that programming only solving problems yourself, and that’s generally what you get paid to do. Sure, you might work with other people, but if you’re constantly bothering them for help they will just assume you’re incompetent.

The key to getting help is to show that you tried to solve it before asking for help. If you hit a problem and you just go, “I don’t understand! Help!” then you seem lazy. But if you go, “Hey, I’m having this problem, and I think it’s this, but I tried X, Y, and Z to solve it and can’t. Can you see something I’m missing?” That shows you did some work before asking for help, but it also forces you to try to solve it on your own.

Now, how do you try to solve it on your own? You guess. In all of your questions you could have compiled a set of possible answers and then made a guess as to the most likely one. If you do that, and then struggle with it for a day before asking for help the probability you’ll find the answer on your own goes way up. And, finding answers on your own is what this is all about.

Finally, another trick is called “rubber ducky debugging”. That’s where you talk to some fake “person” about the problem you need to solve. Traditionally it’s a rubber duck on your monitor, but you can also email the questions and possible solutions to yourself. This works like magic to find solutions because it forces you to articulate your problem clearly and systematically list possible solutions.

Try those tactics next time and you’ll find your learning will vastly improve.