These are pointers for the future, you're probably not ready for them yet in your journey, but I have a few thoughts for you.
# Import your modules
from sys import argv
# unpack argv
script, filename = argv
If zero or more than one arguments were passed on the command line, this will throw an error. You need to think about what your program should do in those cases.
# assign the opened file from argv to the variable txt
txt = open(filename)
"txt" is a bad name. This is a file handle, or open file object, it is not text. Consider using a name that describes what it is or does.
Also, what happens if the file doesn't exist?
# print what you opened and then read the file to the console
print "Here's your file %r: " % filename
print txt.read()
Once you are done with a file it is polite to close it: txt.close(). This isn't essential in Python because it will eventually be garbage collected and the close will be called for you, but it's worth knowing.
# get the filename from the user and assign it to the file_again variable
print "Type the filename again: "
file_again = raw_input("> ")
# open that file and assign the opened file to the variable txt_again
txt_again = open(file_again)
And again, bad variable name.
# read that file to the console
print txt_again.read()
And again, it's polite to close the file when you're done with it.
Yes, but when you're just three days into learning it's good to do things the direct way using fewer language facilities, then grow into the more powerful constructs later when you can better appreciate their value.
Wow, thanks for the pointers. I think I understand everything you are saying up there and will definitely keep it in mind when I start writing my own programs. Right now, this is the program for that exercise written by Zed Shaw, with my comments explaining to myself what each section is doing.
I definitely appreciate you weighing in on it, I love seeing this type of feedback from HN users. Makes me excited to keep learning and become a part of the community.
One convention I use in lots of my code, where I'm doing typical file-esque type stuff, is to call my input file object `inf` and my output file `outf`. Makes it nice and easy to keep them straight.
I can see the utility in that, but fear that I would get confused on what 'inf' means if I don't use it often and come back to old code. I read that as infinite. Maybe something like "inFile" and "outFile"? A little more verbose, but still not too long and easier to deduce the meaning of the variables. Is camel-casing like that OK for variables in Python, or is there another convention that I am unaware of?
Is there any strong argument against camel-casing, or is it just a stylistic preference? I traditionally like it as it's easier to pick out individual words, but I am open to any arguments one way or the other.
I'll admit that's oldschool, and use lots of short variable names, often abbreviated. This tends to be less of a source of error than a typoInAnExtremlyLongAndVerboseVariableName.
Also, what happens if the file doesn't exist?
Once you are done with a file it is polite to close it: txt.close(). This isn't essential in Python because it will eventually be garbage collected and the close will be called for you, but it's worth knowing. And again, bad variable name. And again, it's polite to close the file when you're done with it.